mgrimes at macports.org
Tue Jun 5 00:53:01 PDT 2007
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
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
> 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
> 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
> 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.
More information about the macports-dev