GSoC2007 work

[Mark Grimes]

On Mon, 04 Jun 2007 17:25:13 -0700, Blair Zajac wrote:
> Mark Grimes wrote:
>> On 6/4/2007, "Blair Zajac" <blair at orcaware.com> wrote:
>> I would imagine the last mile is being handled by subversion's roadmap,
>> but I would tend to think that in large multi-developer project's
>> something that coarse grain wouldn't be ideal.
>> 
>> I didn't mean to slant this discussion into battle of the tools -- but
>> what I've researched (granted opted out of) doesn't chalk svnmerge.py
>> as a complete solution in the slightest.
> 
> I think you're being a little dismissive here.  For 90% of the 
> merging people do, merging complete revisions and at a top level 
> directory is sufficient.

Ya I most certainly am being dismissive, it's not on purpose it's easy 
to lose sight on where svk extends svn, as for years svk has vested 
energy on exactly this problem -- svk's no-brainer merge tracking has 
saved my bacon more then a few times, simply because a small contingent 
of developers I work with are branch happy while the rest don't 
acknowledge there is anything but trunk (both dangerous, but the former 
shouldn't be... or at least living with the others that are branch 
happy shouldn't be)  I think it's more of a question of where you want 
to spend your time and not "can from can't do", which is the attitude I 
think I originally aired. Of course you can do it... but wouldn't you 
rather be focused on content then playing chess with your version 
control system.
I'd have a general fear of branching with svn a la carte, but thanks 
for the tip on svnmerge.py, I should reinvestigate it for the 
colleagues that don't listen to my thunderous svk advocacy in the 
hallways at the office. ;)

> We're not talking about the big project here for MacPorts.  We use 
> svnmerge.py in the Subversion project itself on feature branches.  
> Here, most of the time you want to just merge changes from trunk into 
> the feature branch en-masse to keep the branch up to date and not 
> have to keep track of what you have already merged over.  When the 
> branch work is ready, you merge it by hand back into trunk.

Yeah if you don't care about double merging nor evil twins that is. 
Unfortunately, evil twins have bit me all over the place in svn a la 
carte.

> I use svk also, but more for having a copy of a repository on my 
> laptop and being able to do commits then for its merge tracking.

The decentralization is just the most recognized feature, it's 
certainly not the most powerful. When 2.0 was cut at the beginning of 
2007, things got significantly more impressive on a few fronts 
(http://bestpractical.typepad.com/worst_impractical/2007/01/svk_20_is_bette.html)

> We use branches at work all the time.  Each developer gets their own 
> branch and we use trunk to track what's in production web site (Java, 
> HTML code).  So we do svnmerge.py merges from trunk into each 
> developers branch when they want to, and also use svnmerge.py for 
> merge from the developer's branch back into trunk for when new code 
> is being deployed.

Sounds like an architectural design crafted around coarse grain merge 
tracking. At my work, we create functional branches that >1 people play 
in. Without fine grain merge tracking it is hard to divvy up the merges 
between developers... it does seem like the svn players in our repos 
are afraid to branch, maybe from fear that the tree will diverge too 
much from any lengthy work in a branch. Who can blame them, especially 
when the trees themselves are not very atomic with respect to control 
of what other developers are doing. There are countless examples of 
evil twin problems, and in general it's hard to merge by hand when you 
can't control other users that may be doing more immediate merges 
between branches.

> In this case, svnmerge.py does all we need.
> 
> Does svk support more fine grained branch management where the 
> branches live on the server and not in ~/.svk?

You are still doing your work against a mirrored path that throws 
svk:merge tickets all over macports directory structure, so I don't see 
this as acting any different then dealing with local branches that 
offer the same merge ticket system.  svk can inspect remotely mirrored 
svk:merge tickets on the macports tree just the same, so I would gather 
your granularity is at the same level.

If you want to pull local branch management out of the loop, engage all 
your svk commands against the mirrored path and that would basically 
give you "svn" + merge tracking via tickets. This is not a way I've 
ever operated, but I suppose it's completely conceivable since the 
merge tickets litter the server svn repo as props.

Tying the fun tangent back to GSoC, it sounds like it [GSoC] being more 
or less a student exercise then pair programming would benefit from 
svnmerge.py or coarse grain merge tracking if branching is warranted or 
even used discretionarily.

-Mark