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!
> > 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.
It's been discussed before, I know. And this feature has often been
rejected for possibly serveral reasons.
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.
Example:
If you copy something, subversion must assume that you do a copy from one
branch to another, and create mergeinfo.
This causes mergeinfo to be created where we do not need it.
E.g. in case you copy a file to another path within the same branch,
you get mergeinfo on the destination. This is bogus!
It's a result of the idea of making a branch just like a copy.
If we had a command like (warning, crystal ball!):
svn branch ^/trunk ^/branches/mybranch
instead of
svn copy ^/trunk ^/branches/mybranch
where 'svn branch' would work like 'svn copy', but also mark
/branches/mybranch as a "branch boundary", we could avoid this
problem. We could now tell whether copy or move operations cross
branch boundaries, and behave accordingly, e.g. not allow moves
and copies across branch boundaries, but only within branch boundaries.
Only merges would be able to cross branch boundaries.
We could also have:
svn tag ^/trunk ^/tags/1.0
and mark ^/tags/1.0 as a "tag boundary", within which no modification
whatsoever is allowed.
svn tag --list
would list all tag boundaries the repository knows about.
> Subversion lets you do all of this. In an enterprise context, where
> you can't control the calibre of developers, you really need to lock
> this down though -- mainly to protect developers that don't know the
> ins and outs of Subversion more than anything else.
>
> Now that I've got this semantic layer sitting on top of each repo, I
> can write hooks like this:
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?
Stefan
Received on 2009-02-21 12:39:12 CET