4 ms·

I've used RCS, SCCS, CVS, Subversion, SourceSafe, ClearCase, AccuRev, Perforce, and probably at least one more I've forgotten. ClearCase was a garbage fire for

I've used RCS, SCCS, CVS, Subversion, SourceSafe, ClearCase, AccuRev, Perforce, and probably at least one more I've forgotten. ClearCase was a garbage fire for reasons of performance and stability, but none of them had an internal model that was as much of a hot mess as git's. It's not the OP who has forgotten what things used to be like. Maybe you-now understands git better than you-then understood CVS (for example), but that might have more to do with personal learning curves than with inherent complexity.

mbfg 5y ago
clearcase, lock the branch, go on vacation. yeah good model. And then there's the multisite replication mess. Maybe they fixed that in the 20 years since i used it.. but that was a disaster.
fiddlerwoaroof 5y ago
Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated.
- bombcar 5y ago
  Arguably a big part of the confusion around the internal model is that git half-hearted pretends it’s actually just a pile of patches.
- tablespoon 5y ago
  >> but none of them had an internal model that was as much of a hot mess as git's. > Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated. I'll do you one better: it's just some byte arrays on disk. I think the OP has a section that gets at some of the complexity of git's model: > The complexity of Git distracts attention from the software under development. A user of Git needs to keep all of the following in mind: > a. The working directory > b. The "index" or staging area > c. The local head > d. The local copy of the remote head > e. The actual remote head > Git has commands (and/or options on commands) for moving and comparing content between all of these locations.
aidenn0 5y ago
CVS arguably has an internal model that is as much of a hot mess as git's. It's a hack on top of RCS and that fact leaks out in user-visible ways all the time.

mbfg 5y ago

clearcase, lock the branch, go on vacation. yeah good model. And then there's the multisite replication mess. Maybe they fixed that in the 20 years since i used it.. but that was a disaster.

fiddlerwoaroof 5y ago

Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated.

bombcar 5y ago
Arguably a big part of the confusion around the internal model is that git half-hearted pretends it’s actually just a pile of patches.
tablespoon 5y ago
>> but none of them had an internal model that was as much of a hot mess as git's. > Git’s internal model is trivially simple: everything is stored as objects addressed by content. These objects can point to each other. Additionally names can be associated with objects and which object a name points to can be updated. I'll do you one better: it's just some byte arrays on disk. I think the OP has a section that gets at some of the complexity of git's model: > The complexity of Git distracts attention from the software under development. A user of Git needs to keep all of the following in mind: > a. The working directory > b. The "index" or staging area > c. The local head > d. The local copy of the remote head > e. The actual remote head > Git has commands (and/or options on commands) for moving and comparing content between all of these locations.

aidenn0 5y ago

CVS arguably has an internal model that is as much of a hot mess as git's. It's a hack on top of RCS and that fact leaks out in user-visible ways all the time.