On Tue, May 19, 2009 at 05:34:18PM +0100, Bolstridge, Andrew wrote:
> I was browsing the dev list today, and I found a message from someone
> who suggested just this - store a label to revnum mapping in revprop
> 0. Unfortunately he didn't get too favourable a response, possibly
> because the flamewar of "branching v labelling" was still too fresh.
>
> I still think it's a great idea, but I feel the devs think that the
> branch facilities are so great that they *should* be used for tagging.
I'm a dev and I don't think the branching/tagging facilities are as
good as they should be. I think that a lot of the merge-tracking problems
we have or have had (e.g. subtree merge-info being created where it's not
needed) are due to an insufficient destination between copies of
directories and branches and tags. Putting all these concepts together
under "copy" was fine before merge-tracking, but now it creates problems
because e.g. a directory that is the root of a branch is special and
Subversion doesn't know that.
I have not been thinking deeply about it yet, and I would
welcome a discussion on how Subversion could best be made aware
of were branch and tag boundaries are in the versioned tree.
For example, we could have:
svn branch
svn tag
commands, which do what svn copy does nowadays, plus creating
a versioned svn:branch or svn:tag property on the directory
to mark a boundary.
And we'd need to know what effects these boundaries should have
on operations like commit, update, merge, copy, move, add, remove,
and so on. For example, we might not want to allow copies or moves
across branch boundaries.
But this is really high-level thinking and a lot of work needs
to be done before a usable proposal can be made.
> I don't like the tag functionality so far - I'd have created thousands
> of branches to date if we used it (as we release every little change
> explicitly for our customers)
Well, yes, you have to adjust your workflow to Subversion.
As with any other tool. Please show me one version control tool
on the planet that does not assume _any_ particular workflow :)
And note that you can add hook-scripts that make tags read-only by
rejecting future commits to them.
Stefan
Received on 2009-05-20 13:01:43 CEST