6 ms·

An old company I worked for used project management software with a check-in/out mechanism for making changes. When you "check out" a project it downloads a cop

An old company I worked for used project management software with a check-in/out mechanism for making changes. When you "check out" a project it downloads a copy that you change locally, then "check in" uploads it back to the server. A project is "locked" while in the "checked out" state. We all felt it was an archaic mechanism in a word of live updating apps. After 10 years of building SPA "web apps", that data synchronization mechanism feels ahead of its time.

fjcp 3y ago
Looks very similar to JEDI [0], an early Delphi VCS system that worked that way. It gave us the tranquility to know that no conflict would appear, as only one developer could work with a locked/checked out file at a time. There was no merge those days. In contrast, files that were frequently changed in every task would always cause a blocking between developers. [0] https://jedivcs.sourceforge.net/ https://jedivcs.sourceforge.net/
- hnlmorg 3y ago
  There were loads of VCSs that operated this way. And I don’t miss them one bit.
carlsverre 3y ago
I'm a fan of this approach. SQLSync effectively is doing this continuously - however it would be possible to coordinate it explicitly, thus enabling that kind of check in/out approach. As for single-owner lock strategies, I think you could also simulate that with SQLSync - although you may not need to depending on the app. If the goal is to "work offline" and then merge when you're ready, SQLSync provides this pattern out of the box. If the goal is only one client can make any changes, then some kind of central lock pattern will need to be used (which you could potentially coordinate via SQLSync).
alberth 3y ago
Sounds like Lotus Notes.
- handojin 3y ago
  CouchDB is a lineal descendant I guess.
sodapopcan 3y ago
Your comment reminds me of https://joearms.github.io/published/2014-06-25-minimal-viable-program.html https://joearms.github.io/published/2014-06-25-minimal-viabl...
RHSeeger 3y ago
Sounds like RCS [1]. I remember, back when a company I worked for switched from RCS to CVS, one of my coworkers was annoyed that CVS didn't support locking checkouts. [1] https://en.wikipedia.org/wiki/Revision_Control_System https://en.wikipedia.org/wiki/Revision_Control_System [2] https://en.wikipedia.org/wiki/Concurrent_Versions_System https://en.wikipedia.org/wiki/Concurrent_Versions_System
- ethbr1 3y ago
  And, of course, the default mode of Microsoft Team Foundation Server [0], decades after there were better patterns. So many forgotten locks from lazy devs... [0] https://en.m.wikipedia.org/wiki/Azure_DevOps_Server#TFVC https://en.m.wikipedia.org/wiki/Azure_DevOps_Server#TFVC
  - throwaheyy 3y ago
    Are you sure? My experience of using TFVC was that it would warn you if someone else had opened the file for editing but would not actually lock it. Multiple people could edit the same file concurrently with standard automerging/conflict resolution afterwards.
    - RHSeeger 3y ago
      I'm definitely not sure. Could very well be the transition from CVS to Subversion that I'm remembering. It's been a long time :)
    - alistairSH 3y ago
      Server workspaces vs local workspaces, maybe? With server, your local copy was marked read-only. Don’t recall if you could change that flag to edit anyway. We moved to local workspaces as Quickly as we could - that was a more typical offline edit, resolve conflicts at commit model. Don’t remember all the details, been 5+ years since I did anything with TFS.
      - throwaheyy 3y ago
ozim 3y ago
It solves so many problems and makes it so easy to implement if you go this way. But just like mentioned it is hard to convince people that it is what they actually want. People fall into some grand illusion that everything should be always available but in reality then one person is doing changes at a time and if somehow 2 or more people have to work on something - more often than not they should be talking or communicating with each other anyway to synchronize. Even with GIT and fully distributed development you cannot solve conflicts automagically. You still have to communicate with others and understand context to pick correct changes.
- calvinmorrison 3y ago
  you can only have one person work on the code at a time? that seems, very very obviously dumb
  - SkyMarshal 3y ago
    Multiple people can work on the code simultaneously and asynchronously, but conflict resolution must be done synchronously.
  - ozim 3y ago
    I can change A to B on my own, you can change A to C on your own. At some point we have to communicate which change is correct. It does not have to be synchronous and it might be via commit message - but still change alone is not enough for conflict resolution. If you edit word document and someone then changes something there is no commit message but might be comment on document, email or im.
    - __MatrixMan__ 3y ago
      Unison has a neat approach to this problem: References are hashes of the abstract syntax tree, the only way to write a "collision" is to write an identical function--which isn't actually a collision at all.
      - 3y ago
emmanueloga_ 3y ago
flashbacks to working on a team were we needed to shout across the room for people to unlock their source files in MS SourceSafe :-p
pdonis 3y ago
What many people either can't or don't want to acknowledge is that ultimately whether or not you support live updates in parallel by multiple users, instead of locking so only one update can proceed at a time, is not a technical decision, it's a business decision: do the business rules that are appropriate for your application enable you to deal with concurrent live updates or not? Ultimately that comes down to whether you can implement a process to ensure consistent resolution of any incompatibilities between multiple concurrent updates. Sometimes that can be done, and sometimes it can't, and which is the case for your application depends on your business rules, not on any technical capability. If your business rules don't allow you to implement a resolution mechanism, you need locking so that only one update can happen at a time, whether you have the technical capability to support concurrent updates or not.
- Terr_ 3y ago
  Indeed, many of the most painful technical problems are actually three business problems in a trenchcoat.
  - hinkley 3y ago
    Sometimes known as, "two people with firing authority fighting a proxy war through the dev team".
  - pdonis 3y ago
    This literally made me lol. :-)
  - fho 3y ago
    So true ... and often those business decision are not yours to make.
  - ok_dad 3y ago
    This is one of those phrases that should turn into a saying, and be passed around for hundreds of years. Every hard problem I have today in my career involves getting business people to define their business problem properly in order to solve it with technology. Even the hardest code I've ever written was easy compared to some projects, simply due to the business issues lurking around the project. Last week I finished a script to download a CSV and save it to a SQL table (literally) that took 3 weeks because business folks couldn't get their act together on what they wanted. I finished another project in a few days which is currently the core of a previous employers energy efficiency controls product which was easy because the person defining it did it very well, and I had no questions, just work to perform.
pyeri 3y ago
This totally. This is one of the reasons that classical RDBMS paradigms and software like MySQL still survive despite however people want to talk it down in favor of "Nosql" or non-relational databases like mongodb citing how fast it is or how cool it is in comparison. For some things, you need the time tested solutions.

fjcp 3y ago

Looks very similar to JEDI [0], an early Delphi VCS system that worked that way. It gave us the tranquility to know that no conflict would appear, as only one developer could work with a locked/checked out file at a time. There was no merge those days. In contrast, files that were frequently changed in every task would always cause a blocking between developers. [0] https://jedivcs.sourceforge.net/ https://jedivcs.sourceforge.net/

hnlmorg 3y ago
There were loads of VCSs that operated this way. And I don’t miss them one bit.

carlsverre 3y ago

I'm a fan of this approach. SQLSync effectively is doing this continuously - however it would be possible to coordinate it explicitly, thus enabling that kind of check in/out approach. As for single-owner lock strategies, I think you could also simulate that with SQLSync - although you may not need to depending on the app. If the goal is to "work offline" and then merge when you're ready, SQLSync provides this pattern out of the box. If the goal is only one client can make any changes, then some kind of central lock pattern will need to be used (which you could potentially coordinate via SQLSync).

alberth 3y ago

Sounds like Lotus Notes.

handojin 3y ago
CouchDB is a lineal descendant I guess.

sodapopcan 3y ago

Your comment reminds me of https://joearms.github.io/published/2014-06-25-minimal-viable-program.html https://joearms.github.io/published/2014-06-25-minimal-viabl...

RHSeeger 3y ago

Sounds like RCS [1]. I remember, back when a company I worked for switched from RCS to CVS, one of my coworkers was annoyed that CVS didn't support locking checkouts. [1] https://en.wikipedia.org/wiki/Revision_Control_System https://en.wikipedia.org/wiki/Revision_Control_System [2] https://en.wikipedia.org/wiki/Concurrent_Versions_System https://en.wikipedia.org/wiki/Concurrent_Versions_System

ethbr1 3y ago
And, of course, the default mode of Microsoft Team Foundation Server [0], decades after there were better patterns. So many forgotten locks from lazy devs... [0] https://en.m.wikipedia.org/wiki/Azure_DevOps_Server#TFVC https://en.m.wikipedia.org/wiki/Azure_DevOps_Server#TFVC
- throwaheyy 3y ago
  Are you sure? My experience of using TFVC was that it would warn you if someone else had opened the file for editing but would not actually lock it. Multiple people could edit the same file concurrently with standard automerging/conflict resolution afterwards.
  - RHSeeger 3y ago
    I'm definitely not sure. Could very well be the transition from CVS to Subversion that I'm remembering. It's been a long time :)
  - alistairSH 3y ago
    Server workspaces vs local workspaces, maybe? With server, your local copy was marked read-only. Don’t recall if you could change that flag to edit anyway. We moved to local workspaces as Quickly as we could - that was a more typical offline edit, resolve conflicts at commit model. Don’t remember all the details, been 5+ years since I did anything with TFS.
    - throwaheyy 3y ago

ozim 3y ago

It solves so many problems and makes it so easy to implement if you go this way. But just like mentioned it is hard to convince people that it is what they actually want. People fall into some grand illusion that everything should be always available but in reality then one person is doing changes at a time and if somehow 2 or more people have to work on something - more often than not they should be talking or communicating with each other anyway to synchronize. Even with GIT and fully distributed development you cannot solve conflicts automagically. You still have to communicate with others and understand context to pick correct changes.

calvinmorrison 3y ago
you can only have one person work on the code at a time? that seems, very very obviously dumb
- SkyMarshal 3y ago
  Multiple people can work on the code simultaneously and asynchronously, but conflict resolution must be done synchronously.
- ozim 3y ago
  I can change A to B on my own, you can change A to C on your own. At some point we have to communicate which change is correct. It does not have to be synchronous and it might be via commit message - but still change alone is not enough for conflict resolution. If you edit word document and someone then changes something there is no commit message but might be comment on document, email or im.
  - __MatrixMan__ 3y ago
    Unison has a neat approach to this problem: References are hashes of the abstract syntax tree, the only way to write a "collision" is to write an identical function--which isn't actually a collision at all.
    - 3y ago

emmanueloga_ 3y ago

flashbacks to working on a team were we needed to shout across the room for people to unlock their source files in MS SourceSafe :-p

pdonis 3y ago

What many people either can't or don't want to acknowledge is that ultimately whether or not you support live updates in parallel by multiple users, instead of locking so only one update can proceed at a time, is not a technical decision, it's a business decision: do the business rules that are appropriate for your application enable you to deal with concurrent live updates or not? Ultimately that comes down to whether you can implement a process to ensure consistent resolution of any incompatibilities between multiple concurrent updates. Sometimes that can be done, and sometimes it can't, and which is the case for your application depends on your business rules, not on any technical capability. If your business rules don't allow you to implement a resolution mechanism, you need locking so that only one update can happen at a time, whether you have the technical capability to support concurrent updates or not.

Terr_ 3y ago
Indeed, many of the most painful technical problems are actually three business problems in a trenchcoat.
- hinkley 3y ago
  Sometimes known as, "two people with firing authority fighting a proxy war through the dev team".
- pdonis 3y ago
  This literally made me lol. :-)
- fho 3y ago
  So true ... and often those business decision are not yours to make.
- ok_dad 3y ago
  This is one of those phrases that should turn into a saying, and be passed around for hundreds of years. Every hard problem I have today in my career involves getting business people to define their business problem properly in order to solve it with technology. Even the hardest code I've ever written was easy compared to some projects, simply due to the business issues lurking around the project. Last week I finished a script to download a CSV and save it to a SQL table (literally) that took 3 weeks because business folks couldn't get their act together on what they wanted. I finished another project in a few days which is currently the core of a previous employers energy efficiency controls product which was easy because the person defining it did it very well, and I had no questions, just work to perform.

pyeri 3y ago

This totally. This is one of the reasons that classical RDBMS paradigms and software like MySQL still survive despite however people want to talk it down in favor of "Nosql" or non-relational databases like mongodb citing how fast it is or how cool it is in comparison. For some things, you need the time tested solutions.