Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite

I have some experience with Perforce, SVN, and TFS. For SVN, The source files were by default writable after synchronization. However, they were readonly for Perforce, as well as TFS if memory served me.
Meanwhile, 'checkout' means source sync for SVN but its meaning is quite different for other popular tools. I'm wondering which is more 'correct' behavior and why these tools behave differently.
Thanks.

share|improve this question
I think the concept for version control should keep consistent. – fifth Jan 13 '12 at 8:05
1  
Checkout Mercurial and Git, you're in for a big surprise... Also the concept is called "software configuration management", revision control is just a part of it, and you can't really expect different tools to have exactly the same approach in everything, what would be the purpose of having different tools then? There's rarely a "correct way" when implementing a software concept, that's a fallacy. It's a concept, not a formal standard (but implementations of those differ too)... – Yannis Rizos♦ Jan 13 '12 at 8:13
@ZaphodBeeblebrox: But SVN and Perforce are just revision control -- They're nowhere near a full SCM system. (TFS has other features, but is probably not a full SCM either.) – Sean McMillan Jan 13 '12 at 15:17
@SeanMcMillan Hmm, the (subtle?) point of my comment was that the question is unsuitable for Programmers, because OP doesn't seem to had (at least minimally) researched the basic concepts involved in it. The other point was that revision control is part of a larger concept, and several of the subtle differences between implementations are exactly because tools implement (or at least try to) some of the other concepts of SCM (even minimally). – Yannis Rizos♦ Jan 13 '12 at 15:42

1 Answer

up vote 6 down vote

There used to be two different ways or paradigms with source control. These were:

  1. Get latest/checkout (locking for other users)/edit/commit
  2. Checkout (not locking for other users)/edit/merge/commit

The first was used by VSS, whereas svn uses the second by default.

(TFS has evolved from VSS and I believe Perforce used cvs as a starting point)

Using the first paradigm, when getting files from the repository, you haven't said that you want to edit them and the source control marks them as readonly to force you to explicitly 'checkout for edit' the file you want to alter. VSS had commands to 'get latest' and checkout' - and it was checkout that marked the field as editable (and locked it in the repository by default so other couldn't edit the same file at the same time).

This leads to issues if one developer checks out and locks a particular file and then goes off on leave, etc. His colleagues cannot edit the file without breaking the lock or hacking into his account.

Subversion uses the 2nd, edit/merge/commit paradigm. There is no command to 'get latest' without the ability to edit the file - there is only the checkout command. Several developers can modify a same file a the same time.

This leads to other issues at commit. If you and I have both edited the same file, and you commit your changes first, I cannot commit my version without first merging in your changes. There is a risk here that I don't understand the changes you've made and I alter the file so it does what I wanted and breaks the change you had made.

Both paradigms have potential issues, but in my opinion the checkout/edit/merge is better. If multiple developers are editing the same files at the same time and have difficultly merging the changes, I believe you've got problems with the code structure and the inter-team communication that cannot be solved by source control tool alone.

In order to avoid the issue when one developer has a file locked and cannot be contacted to release the lock, some source control systems allowed locks to be broken or overridden. Some also allow the repository to be set such that some files are not locked and then have to be merged prior to commit - i.e. using an amalgamated checkout/edit/merge/commit. Because of their provenance, their 'get latest' command obtains a read-only copy and insists that you 'checkout for edit' in order to get a writable copy, but they then follow the same flow as subversion with the editing and merging before commit. This is how Perforce works.

In order to mitigate the cannot merge changes issue, Subversion does allow the repository to be setup to require locking for some or all files. (I’ve used this is the past to ensure MSWord documentation that was a pain to merge could only be updated by one user at a time, and similarly with picture/icons.)

share|improve this answer
1  
CVS was the first tool that used the edit/merge/commit cycle by default, though it does support locking (so please remove "and I believe cvs"). Subversion does support locking, so you should say "by default uses the second", not "always uses the second" (only distributed systems always use the second, since they don't have a central authority to arbiter any locks). – Jan Hudec Jan 13 '12 at 9:13
@JanHudec Thanks, my memory is obviously not what it used to be. Updated accordingly. – Grhm Jan 13 '12 at 9:55
@Grhm, first I agreed that checkout/edit/merge style is better. Secondly, like what you said, explicit 'lock' command should be better than 'checkout' and 'lock' by default, and it's the way I think how tools evolved. Thanks. – fifth Jan 13 '12 at 11:29
Also, there's another cool advantage of the checkout/edit/commit approach: You can query the VCS to find out who is currently working on which file(s). – Stephen Gross Jan 13 '12 at 18:29
I'm not disputing your answer, but TFS probably has more in common with perforce than VSS. MS use(d) a customised version of perforce internally. Also the next version of TFS will add local workspaces which will behave in a similar way to SVN – James Reed Jan 13 '12 at 21:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.