undefined | Better HN

story

0 pointsrswail11mo ago0 comments

Which is exactly how CVS (and its predecessors RCS and SCCS) worked.

They were file based revision control, not repository based.

SVN added folders like trunk/branches/tags that overlaid the file based versioning by basically creating copies of the files under each folder.

Which is why branch creation/merging was such a complicated process, because if any of the files didn't merge, you had a half merged branch source and a half merged branch destination that you had to roll back.

0 comments

fanf211mo ago

CVS was called the “concurrent version system” because it did not lock files on checkout. Nor did svn. Perforce does.

ack_complete11mo ago

Perforce does not lock files on checkout unless you have the file specifically configured to enforce exclusive locking in the file's metadata or depot typemap.

rswailOP11mo ago

True dat, my mistake. That was its major feature, from memory though it still used the same reversed diff file format?

umanwizard11mo ago

I am quite sure that you can edit files in an svn repo to your heart’s content regardless of whether anyone else is editing them on their machine at the same time.

masklinn11mo ago

Yep, svn has a lock feature but it is opt-in per file (possibly filetype?)

A pretty good tradeoff, because you can set it on complex structured files (e.g. PSDs and the like) to avoid the ballache of getting a conflict in an unmergeable file but it does not block code edition.

And importantly anyone can steal locks by default. So a colleague forgetting to unlock and going on holidays does not require finding a repo admin.

j / k navigate · click thread line to collapse