[Adium-devl] VCS + SVN 1.5
Augie Fackler
lists at durin42.com
Wed Dec 26 02:48:18 UTC 2007
On Dec 25, 2007, at 8:15 PM, Augie Fackler wrote:
>
> On Dec 25, 2007, at 6:52 PM, Colin Barrett wrote:
>
>>> * Augie, you've been a proponent of subversion 1.5 in the past.
>>> Could you brief us, in a new thread, on how branching & merging is
>>> best accomplished using that? I'm wholly enamored of monotone at
>>> this point, 99% for its branch & propagate model which requires no
>>> tracking by its users.
>>>
>
> Frankly, SVN 1.5 is stalled. Like, really stalled. They've hit some
> major snags in the merge tracking for now (some design issues came up
> in (if I understand correctly) the treatment of branches as cheap in-
> filesystem copies). If you want branching + merging _now_, you'll need
> to migrate to something else. I have to admit I'm a bit more taken
> with Mercurial than Monotone (it's been *tons* faster for me), but it
> really doesn't matter much what we end up using. Monotone might make
> more sense because then we've got one VCS across us and Pidgin. Since
> mtn supports pushing (it *does*, right?) it'll be fine for us.
>
> When SVN 1.5 works, which is an indeterminate point in the future
> (I've been a bit out of the loop on how long it's projected to take.
> There are some reflective merge problems that I don't quite
> understand.
>
> That all said, we can *probably* use svnmerge.py to get most/all of
> the merging features we need. SVN 1.5, when it exists, will have a
> clean migration path for svnmerge.py's mergeinfo.
>
> My concern with mtn is that if we switch to it, we need a better intro
> to using mtn than I've seen around - most of the existing explanations
> are too much too quick for most users IMO.
>
> I don't know what really gives us a better end result. If we do move
> to mtn, I think it might make the most sense to just do a clean import
> and keep the svn history intact as-is so we don't have to screw around
> with the old branches and stuff on disk in mtn.
>
> We should come up with a list of options and evaluate them. The three
> I see as most viable right now are svn+svnmerge.py, hg, and mtn. We
> could try svnmerge.py now, and I'm willing to try and work with people
> on that.
>
> Peace,
> Augie
>
http://code.google.com/p/sv-subversion/
Just found this. It looks like another possible merging solution, but
I'll have to look at it more later.
> (My name is Augie, and I'm a version control and build systems junkie.
> Admitting I have a problem is the first step to a solution.)
>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
More information about the devel
mailing list