Unreserved Checkouts
Unreserved CheckoutsThe merge on checkin model generally works well. Well enough that exclusive checkouts are unnecessary. Even with hundreds of developers, conflicts are rare, where there are conflicts, they are often easy to merge, and the rest is pure hell. Nothing compared to the hell of waiting on people to make their changes, test, and checkin, etc.
Knowing who is working on what doesn't require exclusive checkouts, and is valuable enough that I think it should be in the system. I've worked with two systems that had "soft" (non-exclusive) checkouts and "hard" (exclusive) checkouts, and with CVS, and I prefer the former. It's very useful knowing what other people are working on, and the source control system is ideally placed to maintain that information.
What would happen if everyone checked out a file for just a few seconds, edited it correctly, and checked it back in? [Note: this question may be deeper than it seems.]
And: what if your SCM system, on check-in, could safely determine the difference (within the confines of a single file or other LexicalUnit?) and automagically merge the differences? One reason for defaulting to exclusive checkout with VSS is because the merge is less than adequate, while the CVS merge is at least smart enough to give up and abort on incompatible changes (and is typically pretty conservative about 'incompatible').
I think the best you can do with ANY file-based source control system is to ensure that the each file that is about to be checked in was read (checked out) after the most recent check in. Having multiple files checked out is not a problem so long as each is re-read (to collect changes from other sources) before being checked back in. This solves the situation where multiple developers check out the same file (because, for example, it is included in a project each is working on) but most don't change it.
The real problem, though, is the attempt to perform change management with a grain size that corresponds to files when the actual changes, by construction, correspond to language elements. This is why Envy Developer is so superior (in Smalltalk and Java) to all the file-based competitors. A typical example is a shared class (like String) where Joe needs to change one method and Harry needs to change another. When both methods are in the same file (which Java forces), then Joe and Harry are forced to argue about who goes first even while their changes are mutually compatible. A better change management system tracks changes at the method level, so that Joe and Harry only argue when they each attempt to change the SAME method simultaneously.
The file-as-versionable-element is something that SubVersion, the heir apparent of CVS, is also trying to get away from, but going the other way, making directories, renames, and file meta-data versioned. http://subversion.tigris.org/
(From ReleaseEasyReleaseOften, where once more "release" as in FrequentReleases makes a guest star appearance in a discussion of "release" as in SmallReleases.)
Warning: Use a real versioning system like SourceSafe and unlike CVS, or else the multiple checkins will kill you. -- SunirShah
What seems to be the problem with 'multiple checkins'? I assume that actually means 'non-exclusive checkouts'..
No, it's merely that you don't know who else is working on the same file (by default), which causes more headaches than it's worth. More explicitly, CVS needs to enforce the ParableOfTheBook. This I gather is difficult because it is console based, but the console is not appropriate for this application. -- SunirShah
What sort of problems do you have with conflicts, Sunir? In my experience, letting multiple developers work on the one file makes things easier; the conflicts (when they happen) are easy to resolve, and you can keep on working. Contrast it to VSS, where you can easily find that to do what you need to do to finish the task you've spent four hours working on, you need a file that someone just locked. -- RobertWatkins
I've also never had these problems with CVS. Multiple checkins are a sign of a communication problem, not a source code control problem. I.e. developers should communicate so you know no-one will be working on the same code. There was a time when I though technology should solve these problems, but that time has passed. -- NoelWelsh
I don't want to lock files. I do want to know if other people are working on the same file. Then we can use bio-sonic/optical merge synchronization. i.e. "Hey, Bill, I'm screwing with foo() in Bar.cpp. What are you doing in Bar?" "I'm fixing bug Zeph!" "Me too!" "Ok, why don't you finish it and I'll go have a donut." "Screw you, Bill." -- SunirShah
CVS allows you to do this by setting up watches on the files. Or did you mean something else? -- KyleBrown
Aye, and enforcing edit/unedit. That's not the issue. The issue is having a nice user interface to inform you visually, without you requesting it, in a simple manner, what else is going on in the tree. This is not a small point. I direct you to RecentChanges to show you how useful information about the system can be. Having the ParableOfTheBook is even better (and it would avoid excessive EditConflicts). -- SunirShah
EditText of this page
(last edited September 15, 2011)
or FindPage with title or text search