On Sat, Feb 21, 2009 at 11:37:18AM +0000, Stefan Sperling wrote:
> On Fri, Feb 20, 2009 at 09:45:48PM +0000, Trent Nelson wrote:
> > On Fri, Feb 20, 2009 at 04:22:18PM -0500, Bob Archer wrote:
> > >
> > > > Ah hah! That is the best thing I've read all month. I can simply
> > > > do that in a post-commit hook after detecting that a branch has
> > > > just been re-integrated. Sweeeet.
> > >
> > > I'm not sure how you are going to detect that. As far as the server
> > > knows this is a commit no different than any other.
> >
> > % find ~e/data/python/lib/shell/svn -type f -iname "*.py" | xargs cat | wc -l
> > 6632
> >
> > With a 6000+ line Python framework, that's how ;-)
>
> Would you be able to share all those lines with the community under
> an open source license?
>
> Seriously, releasing such add-ons as open source is a nice way to
> give back to the Subversion community. Others have done this before,
> see e.g. http://trumerge.open.collab.net/
>
> Please consider doing this!
Yeah I definitely want to feed this work back into the community.
It's got a lot of hard-coded client logic built into it at the
moment so it's not something I can immediately upload publicly.
I think it will be a good reference point, if nothing else, for
how one might go about approaching this problem domain. If you're
interested in the implementation I don't mind sending you a code
drop in private so you can get an idea of the approach I've used.
> > > If it were this easy, wouldn't the svn devs be able to do this. But,
> > > then again, they could create a merge property on the target of the
> > > --reintegrate to identify it as such and then when that property is
> > > committed it could update the merge properties on the branch the
> > > property references.
> > >
> > > Hmm... seems too easy... what am I missing?
> >
> > It was far from easy. It's sucked the life out of me for the past
> > three weeks or so. I had to build another semantic layer on top of
> > Subversion, such that, for a given repository, you would define the
> > paths that correspond to trunk, tags, and branches, such that you
> > can analyse a commit and figure out exactly what a user is doing.
> >
> > Are they trying to copy a tag? Are they trying to create a branch
> > from a tag? Have they correctly rooted their commit (i.e. they're
> > not committing files in branch/foo as well as trunk)? Are they
> > trying to re-integrate more than one branch at a time? Are they
> > trying to revision merge a branch back to trunk when they should
> > be re-integrating? Are they reverse merging, and if so, are they
> > reverse merging within the agreed parameters (i.e. only allow a
> > commit to be a single reverse merge of a previously re-integrated
> > branch; no multiple reverse merges or combined forward+reverse
> > merges are allowed). Are they trying to modify a tag in any way,
> > shape or form?
>
> Interesting!
>
> Can you please share your experience with this as you keep using it,
> especially regarding what gotchas you run into treating certain
> paths as roots for branches and tags etc? I'd really like to know
> how this works out in practice, because I'd like to see (i.e. help
> implementing) functionality like this in Subversion core at some point.
Nod, it's still rapidly evolving as I run into issues. I'm on my
third re-write of the logic that analyses the addition of mergeinfo
for a given commit in order to discern if it's a re-integration, pa-
rtial re-integration, synchronisation or partial synchronisation,
for example. (Granted, I'd never touched the Subversion API or bin-
dings before this work, so there's been a bit of a learning curve
as well.)
> Now, I have not thought about it much myself, but I hope we might be
> able to solve some of the merge-tracking / tree conflicts problems
> with a scheme like the following.
>
> As you know, 'svn copy' is essentially overloaded with many different
> meanings (at the semantic level the tool currently does not care about).
>
> Because of this, subversion does not know where in the repository hierarchy
> branches and tags start. I think we're starting to seriously hit the
> limitations of this with the dawn of merge-tracking, and also tree conflicts.
Yup, you've nailed it. Could not agree more.
> Do you think that the idea outlined above, perhaps in combination with a
> configurable policy that decides what is allowed to cross branch/tag
> boundaries (with a sane set of defaults), would solve your problem as well?
It would certainly solve a big subset of the main issues I've had to
explicitly guard against. The thing I find the most amusing about
all this work I've been doing is how much the solution is naturally
gravitating towards something that looks a lot like UCM ClearCase.
And you know what? I don't actually think that's a particularly bad
thing, especially when you're trying to deploy Subversion in an ente-
rprise context. UCM ClearCase is fantastic from an SCM purists POV;
it's just a pity it's such a dog to use, deploy, administer, etc.
If there was an 'Enterprise Subversion' offering that combined the
speed and unobtrusiveness of base Subversion with the SCM patterns
supported by our commercial counterparts -- that would hit a very
sweet spot, I think.
I really *do* want to share the work I've done so far, even if it's
just used as the basis for more discussions... My solution is ent-
irely hook-based, and has turned out pretty well -- so I'd be inte-
rested in hearing what parts people think should belong in the svn
API versus what should just be left to hooks.
> Stefan
Trent.
Received on 2009-02-26 06:51:01 CET