Mark Mielke wrote: > On 01/07/2010 02:11 PM, Branko Čibej wrote: >> Mark Mielke wrote: >> >>> On 01/07/2010 04:42 AM, Branko Čibej wrote: >>> >>>> Mark Mielke wrote: >>>> >>>> >>>>> The model is a bit easier to implement in ClearCase and GIT, since >>>>> these are both effectively the working copy is a different stream >>>>> from >>>>> the parent whereas Subversion designer work flows tend to work >>>>> directly on "trunk". >>>>> >>>>> >>>> In both ClearCase and GIT (and more so in ClearCase) you pay for it by >>>> requiring "someone" do constantly merge stuff to some "stable" >>>> mainline. >>>> Moreover, the per-developer branch model is just one way of using >>>> ClearCase and IMHO one of the more broken recommendations. >>>> >>>> >>> ClearCase on its own is nearly useless as an SCM. For those that don't >>> know ClearCase, I simplified it to "a sensible and mature wrapper >>> developed around ClearCase". In this case, a sensible and mature >>> wrapper does not require "somebody" to do constant merging any more >>> than Subversion requires the working copy to be merged with HEAD. It's >>> a single "commit" operation which, and the commit handles the merge. >>> >>> In our case, it happens to be called "deliver". The deliver is most >>> similar to "merge --reintegrate", only it always works, and can be >>> done reproducibly. >>> >> Sorry, I didn't quite parse that. are you saying that you can reliably >> automate merging and conflict resolution? 'Cos I don't buy that. You can >> automate it maybe 95% of the time, depending on how much overlap you >> have; but the last 5% is always manual, unless you can also automate all >> of software development. >> > > Automatic merging and conflict resolution even across renames works > extremely well. When it fails, something similar to TortoiseUDiff > comes up to help resolve the situation. It isn't perfect - but it is > definitely better than Subversion 1.6 today. I haven't decided whether > GIT is better or worse than what we have today under ClearCase - they > seem to be do different portions of that last 5%. > >> And when you come down to that, there's no real difference between your >> "wrapped-clearcase" and Subversion's "update-modify-merge" on a single >> branch. >> > > Subversion's model is more limited (only one commit per working copy > for example, and no ability to save changes at intervals), but yes I > agree and this was one of my points. Subversion relies on automatic > merges today to be usable, so it's not exactly a horror as a model. > It's a good model. Subversion just isn't as capable in terms of > extending this to real sub-branches. Conceptually they are the same. > In practice, Subversion treats them differently and limits the common > use. > >>> To prove this, we have developers on Subversion today who make the >>> SAME mistake developers on other systems such as GIT or ClearCase with >>> side streams do. That is, they'll work in isolation for three months, >>> and then try and commit. Under Subversion today, they do a checkout, >>> work in isolation for three months, and then try and update and commit. >>> >> But that has nothing to do with the version control system you use. as >> you say here: >> >> >>> This usually fails and they expect us to fix it for them. They worked >>> on a "side stream" called the Subversion working copy, and their work >>> diverged from trunk for too long to allow easily merging their changes >>> back. They should have updated frequently, or in GIT they should have >>> "git pull"ed frequently, or in ClearCase/UCM they should have >>> "rebase"d frequently. It's the exact same concept. Subversion has not >>> solved the problem by limiting people to one off-stream commit - >>> they've just encouraged a shorter life cycle by limiting the >>> capabilities of the working copy. >>> >> I don't understand how you propose to fix developers by changing a tool. >> > > That's not my proposal. My intent was to show that an automatic > merge-based model is not a "horror", and that the models (working on a > side-stream, working on a side-working copy) are conceptually similar > with similar risks. Designers who do stupid things need to have their > hands slapped or be burned by their own mistakes until they learn not > to do that. :-) > >> Forbidding mixed revision working copies (e.g., but making every commit >> an implicit update) isn't going to help if your developer only commits >> once every two weeks. The only thing that will help in the long run is >> >> * educating your developers >> * having a proper CM (branching, etc.) policy in place >> * educating your developers, and >> * educating your developers >> > > Correct. > >> Good support for merging is essential, yes; tool performance is >> important, yes; but neither is a replacement for doing things right. >> >> I know from bitter experience that some people simply are unable or >> refuse to learn to co-operate, but that's a "management" problem and no >> amount of tweaking your toolset and processes is going to help there. > > Yep. > > But, I do expect that if user B does rename + merge, and user A does > "svn update", that this will work properly. > > I similarly expect that if user B does rename + merge on a > side-stream, and merges to the parent (using --reintegrate or > whatever), and user A does "merge" from the parent stream to their own > side stream, that this will also work properly. > > Both are conceptually similar. The side-working copy is a special > limited case. In Subversion, emphasis was put on the side-working copy > case and side-streams seem more of an after thought enhanced later, > but still incomplete. In GIT, emphasis was put on the side-stream case > and the working copy *is* a side stream. End result? GIT works as I > expect. Subversion does not. :-) (And our existing ClearCase solution > works very well in this scenario as well) > > I'm hoping this can be fixed!
Apparently we're on the same page then and just managed to talk past each other. -- Brane
