Subject: Event 2010-10-25: Distributed Version Control - by: mbools

@vinnyjames
I think you assumed I meant 'DVCS like local copies of the repository history' when what I actually wrote was 'local history---a little like DVCS'. I confess that the added 'a little like DVCS' could be misinterpreted. There have been plenty of announcements about Subversion 1.7 changes to the working copy...

Like this.

Looks very much like an announcement on the Subversion Community site (which is sponsored by your organisation isn't it?) that the Subversion 1.7 will have...
Next Generation Working Copy (WC-NG), enhancing the existing working copy functionality with centralised metadata storage and improved extensibility. This will provide the groundwork to allow offline commits and other features associated with Distributed Version Control Systems (DVCS) such as Git and Mercurial.

Oh, and here's the original press release from WANDisco.

While details are a bit sketchy, "offline commits" and " other features associated with Distributed Version Control Systems", to me, implied maintaining at least a simple working copy history. What use would an "offline commit" be if it did not maintain a local history of these "offline commits"? I think that, in light of this announcement, my observation that there were moves to make '... Subversion working copies maintain local history---a little like DVCS' was not unreasonable.

And this presentation (pages 12-16) in which the idea of "shelving" ("Offline commits") is once again mentioned.

And this article (scroll down to section 2 "SVN vs. GIT, Mercurial and Bazaar", which again mentions shelving and "distributed VCS storage".

There's plenty more, just Google "Subversion 1.7". As I said, I may have misinterpreted what "offline commit" means, but if it does not mean some sort of locally maintained history what use is it?

As for the rest, it was not my intention to start a long debate about the relative merits of DVCS versus central server VCS. I am more than happy to have that debate and I see much merit in both models. I would suggest however that we take any future debate over to the General forum where it will enjoy a larger audience and more participants.

Briefly, to your point about a full history being more useful to a miscreant than a 'sandbox' because they could (with sufficient patience and skill) divine management intentions etc. from such a repository. What you say is true of course, but any machine that exposed such a repository would probably contain information of that sort in a much more readily accessible form (emails, developer notes, meeting minutes, documentation, models, plans, etc.) Any organisation concerned in the slightest about laptop security uses low level encryption systems like SafeBoot (I think it's now called McAfee Endpoint Encryption) to protect the whole asset, so the concerns about information falling into the wrong hands are moot aren't they? This whole "you have your entire product history on the laptop" is a bit of a red herring. Security should be much better than relying on the fact your developers are only carrying around part of your code's history.

Besides (while we're conjuring bogey men), in most organisations where I've used Subversion the developers cache their username/passwords. If we're dreaming up a bad-guy smart enough to divine management intentions from a code base, then I suggest he's also smart enough to not even bother stealing the laptop, he just copies the user's cached credentials and then merrily surfs around the central repository. (And yes, there are plenty of ways to protect against this risk, but then we were positing an organisation so dumb they would not encrypt laptops holding their code base and other IP.)

I never said 'DVCS isn't stored in silos', I said 'It is equally silly, hysterical, and ill-informed to say DVCS are "disparate silos of data..." stored on "laptops and ad-hoc servers"'. I was making an observation about the tone of the message, not the fact of it (although I do challenge the implications of what you wrote).

My original point was not to favour one solution over the other (I really don't, I like to understand the problem to be solved before deciding on the solution), but to point out that a blanket statement that "solution X" is right and "solution Y" is wrong without knowing the specifics of a situation was rather silly.

Okay, if you're interested in a debate about the relative merits of different approaches to version control, then please address it on the General Forum where I'll be happy to engage (and I am certain you will get many more different, interesting, and heated, views on the topic from the very smart and well informed CM practitioners who hang out there).

View the original article here

Subject: Configuration Management the build system's job? - by: mbools

I have always maintained, and continue to maintain, that "build" is not a part of CM nor vice versa. They are two distinct practices. In my view, build is a step in the creation of a product and as such is part of the line function (in the old management terminology of line and staff).

Build is in essence the action taken to translate man-readable material (source) into machine-readable material (executable).

Determining the components to include, which versions of the components, which set of build instructions, and which build engine is the responsibility of someone such as the team lead or PM. Putting the package together for the build and delivering it to the Build Engineer (BE) is the role of the CM specialist. Those duties are not part of actually performing the build.

Now often the person who is assigned to the role of CM Specialist is also assigned to the role of BE. Why? Probably because it is cheaper. You don't have to hire and pay for the benefits of a separate BE.

With all that said, it may be that the build system contributes to CM activities if the system has features that normally are done by other means. For example, in the old days, versioning/revisioning was done by hand. Someone finally automated that so that a CM tool would do it as updated files were checked in. Now if you have a build system that contributes to that, then you could claim that the system contributes to CM activities. But that is a long stretch from saying that either one is a part or subset of the other.

View the original article here

Multi branch / distributed development support - by: mbools

Ah, yes.... and no.
Subversion sees the revision you create during the merge between branches as a new change (which strictly speaking it is as there's no way to know that you did not take action to resolve conflicts for example). So, although it can 'see' that change 123 has been integrated it cannot know that the merge change can be taken on faith, as it were.
This is where you might get conflicts when you 'drop' the source branches. Subversion sees, and ignores, 123 but 233 is a new change (just like the problem you have when bringing a --reintegrated branch back to life where the revision created on trunk is seen as a 'poison' revision in any subsequent integration from trunk to branch). You can always 'fix' the problem with the --record-only trick to tell Subversion to ignore some revisions during the --reintegrate. Merge with a --record only from the branch into the trunk will essentially tell Subversion that you are happy that the change is already dealt with.
Using the previous example, suppose the merge between branches resulted in revision 233 being created and I then drop the sourcebranch into the trunk (--reintegrate), I can forewarn Subversion that 233 should also be ignored in any future trunk merge using the --record-only merge technique. This should only be used if 233 was created without any incident (no additional action taken when merging between branches, otherwise I may overlook some legitimate integration issues).
No tool can reliably and automatically account for this sort of thing because during the merge between branches I may have to perform all sorts of integration actions both resolving direct conflicts and also potentially performing changes to different parts of the code base to accommodate the integrated change (123). The tool can only 'blindly' resolve the record that change 123 has been integrated with 233 (which Subversion does), it cannot understand any other actions taken in 233 and so will have to account for that in the drop to trunk. This requires a human to say 'well, actually 233 has no special actions in it, so go ahead and ignore it'. I guess a tool could look at 233 and infer that, if all the deltas in 123 and 233 are identical, then 233=123, but beyond that I think a person is needed to make a judgement call as to whether 233 can be ignored completely, ignored in part, or not ignored at all.
There are ways to minimise problems of this sort (by limiting the scope of changes, making changes as small as possible, integrating changes in parts; those that need no special actions and those that do, etc.) but that's all a bit beyond this thread or my capacity to explain in a single post
Hope that all makes sense
View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Just so I keep my wires straight (it's not clear from the other posts on this thread), what do you mean by having problems with baseless merges?

View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Ah, perhaps you were asking whether someone from another branch could --reintegrate between 5 and 6. Well, yes, but that's not a problem.

Suppose I 'drop' the branch as follows.

cd ~someone/trunk/wc
svn update
svn merge --reintegrate ^/branches/somebranch .
svn commit

Creating revision 123. This revision 123 is the 'poison' revision that will cause all sorts of trouble if we tried to merge from trunk into branch again.

Anyhow, I can sync (at pretty much any time between the drop and the next time I want to pull trunk changes up into somebranch) with:

cd ~someone/somebranch/wc
svn update
svn merge -c 123 --record-only ^/trunk
svn commit

Note, I am specifically merging only the poison revision in order to prevent problems in future. There is nothing in revision 123 that will impact the branch (it was, after all dropped from branch in the first place). Even if someone from another branch had, in the meantime, dropped revision 124 this would in no way be a problem.

Next time I merge trunk into somebranch I will see 124 as a new trunk change (no different to seeing any other trunk change) and revision 123 will be seen as 'already merged' because of my --record-only merge earlier, hence it will not cause trouble.

Even if someone adds to the somebranch before I do the bookkeeping --record-only merge it does not matter. Just so long as the bookkeeping is done before the next merge from trunk.

If you're disorganised and allow a change on trunk between the last integration into the branch and the 'drop' then you may have an issue, but that issue will simply be remerging work, Subversion will keep track of it just fine.

Suppose trunk was at 120 when you integrated up to somebranch (bringing somebranch up to date with the head of trunk). Then someone updated the trunk, adding 122. Then you 'drop' somebranch to create 123 on trunk (it would be better to pull 122 into somebranch, rebuild, retest and then drop---but let's suppose you need to mess trunk about for some reason). There may be some merge work in trunk between 122 and 123 changes. If you then merge --record-only 123 up to somebranch the next time you integrate trunk up to branch you will need to 'remerge' revision 122. The best way to avoid this is to stop working on trunk. Use trunk as a 'release' branch and use 'support' branches for defect resolution etc. That way you keep control over your integration patterns and can avoid this sort of complexity.

Maintaining trunk in this way also makes the 'drop' simpler because you can 'merge --reintegrate' and 'resolve --accept theirs-full' (not that this should be necessary if you're merging is organised properly). Assuming you make sure the source branch is always up-to-date with respect to branch before dropping (and why would you not? If you are merging during a release you are releasing untested code, which is pretty risky stuff---unless your system is properly segmented into sub-systems/modules in which case you are releasing these CI, and the providing the merging effort is isolated to one CI you should have no issues, but this is getting too complex for a forum post and somewhat off topic, so I'll stop now).

View the original article here

Subject: Multi branch / distributed development support - by: mbools

Tekkie:

Ah, perhaps you were asking whether someone from another branch could --reintegrate between 5 and 6. Well, yes, but that's not a problem.

Suppose I 'drop' the branch as follows.

cd ~someone/trunk/wc
svn update
svn merge --reintegrate ^/branches/somebranch .
svn commit

Creating revision 123. This revision 123 is the 'poison' revision that will cause all sorts of trouble if we tried to merge from trunk into branch again.

Anyhow, I can sync (at pretty much any time between the drop and the next time I want to pull trunk changes up into somebranch) with:

cd ~someone/somebranch/wc
svn update
svn merge -c 123 --record-only ^/trunk
svn commit

Note, I am specifically merging only the poison revision in order to prevent problems in future. There is nothing in revision 123 that will impact the branch (it was, after all dropped from branch in the first place). Even if someone from another branch had, in the meantime, dropped revision 124 this would in no way be a problem.

Next time I merge trunk into somebranch I will see 124 as a new trunk change (no different to seeing any other trunk change) and revision 123 will be seen as 'already merged' because of my --record-only merge earlier, hence it will not cause trouble.

Even if someone adds to the somebranch before I do the bookkeeping --record-only merge it does not matter. Just so long as the bookkeeping is done before the next merge from trunk.

If you're disorganised and allow a change on trunk between the last integration into the branch and the 'drop' then you may have an issue, but that issue will simply be remerging work, Subversion will keep track of it just fine.

Suppose trunk was at 120 when you integrated up to somebranch (bringing somebranch up to date with the head of trunk). Then someone updated the trunk, adding 122. Then you 'drop' somebranch to create 123 on trunk (it would be better to pull 122 into somebranch, rebuild, retest and then drop---but let's suppose you need to mess trunk about for some reason). There may be some merge work in trunk between 122 and 123 changes. If you then merge --record-only 123 up to somebranch the next time you integrate trunk up to branch you will need to 'remerge' revision 122. The best way to avoid this is to stop working on trunk. Use trunk as a 'release' branch and use 'support' branches for defect resolution etc. That way you keep control over your integration patterns and can avoid this sort of complexity.

Maintaining trunk in this way also makes the 'drop' simpler because you can 'merge --reintegrate' and 'resolve --accept theirs-full' (not that this should be necessary if you're merging is organised properly). Assuming you make sure the source branch is always up-to-date with respect to branch before dropping (and why would you not? If you are merging during a release you are releasing untested code, which is pretty risky stuff---unless your system is properly segmented into sub-systems/modules in which case you are releasing these CI, and the providing the merging effort is isolated to one CI you should have no issues, but this is getting too complex for a forum post and somewhat off topic, so I'll stop now).

View the original article here