John Hunter wrote: > On Jan 7, 2008 2:37 PM, Eric Firing <[EMAIL PROTECTED]> 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
