John Hunter wrote:
(At the moment I can't compile the branch--I just sent Mike a message
about that off the list, with voluminous output.)
It seems like what is needed is not exactly a merge operation but simply
a renaming of the trunk and the branch. Maybe some doc files need to be
merged, but that is about it. Correct?
Sorry if I used sloppy terminology, all I mean is that Michael's stuff
will become the HEAD of the svn trunk, and the current HEAD of the
trunk will become a branch. No merge will be necessary since Michael
has been merging all changes in the HEAD into his branch on a ongoing
basis. I don't actually know how one does this move in svn, but I
have faith that Michael does.
I've been using svnmerge.py
http://www.orcaware.com/svn/wiki/Svnmerge.py#Quick_Usage_Overview
Essentially, it eliminates the need to remember the last points at which one branch was merged into another (which IMHO is the awful thing about svn's built-in merge). I understand this functionality will be brought into SVN proper in 1.5.
It also has a facility to merge the branch back into the trunk once we're ready. (Whether it's technically a merge or a copy, I don't really know -- that's where the line gets blurry. The point is, it should be straightforward.)
All this brings to mind the discussion taking place over the last week
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
(I have been using hg locally for a couple years, and I like it.) The
motivation is the greater ease of branching and merging with distributed
VCS systems in comparison to SVN. In the numpy list discussion, it
sounds like all participants except Travis favor making the switch.
I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,
Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.
David Cournapeau seems to have had some non-specific bad experiences with svnmerge.py. I agree, it does force you to be explicit (i.e. set up the branch correctly from the start), unlike a DVCS where it is built-in. But I've had absolutely no problems with it (maybe I'm just lucky).
I had hesitated to add to the discussion, since so much has been said already over on numpy. However, besides the merge-tracking (that svnmerge adequately meets for me) I see one other important advantage to DVCS: It's easier to create local and non-official branches (meaning created by developers without write access to the "official" repository), and track changes that aren't really ready to be shared. I worked at a place (that shall remain nameless), that used a centralized VCS, but the culture (as mandated by management) was to commit to the trunk only very rarely, usually right before an alpha or beta cycle. This meant that it was a) hard to keep track of what others were doing, b) there was a high likelihood of conflicts with others (not just at the source code level, but the logical level), c) all the ad-hoc testing that developers do as they write code had to be completely redone after this "merge" and long after the developers had forgotten about what they had written. I'm a strong believer in "continuous integration" of code. It seems to me that at its worst, a DVCS lightly discourages continuous integration because it makes it so easy to go off on tangents, and tangents aren't necessarily always a good thing if the end result is intended to be truly "one product". Tangents are necessary, yes, but their number needs to be somehow limited. This is all a matter of process, of course, and neither approach to version control really prevents any particular process -- I'd just like to make the argument that the "lots of little branches" process that DVCS make so easy, is not necessarily always appropriate.
Lastly, it seems to me that there are upteen ways to emulate a DVCS on top of a core repository that is still running on SVN. For instance, I used SVK (a DVCS specifically designed to be used in conjunction with SVN) in the above situation to maintain my sanity and keep my own local revision history. It also helps with laptop situations. Nothing is stopping anyone from doing that today, and we don't even need to know about it. I'll admit it's not really the same thing (there's would be no single way for someone else to get at my local changes), but it meets a lot of the needs with no organizational impact on others.
All this is to say, I'm sort of -0 on this -- I see as many plusses and negatives, I guess.
Cheers,
Mike
···
On Jan 7, 2008 2:37 PM, Eric Firing <efiring@...229...> wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Sorry, sorry, I'll go away now.