On Mon, 04 Jun 2007 17:25:13 -0700, Blair Zajac wrote:
Mark Grimes wrote:
On 6/4/2007, "Blair Zajac" <blair@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.h...)
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