[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion "labels" vs. "tags"

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-06-03 22:42:57 CEST

Tim Hill wrote:
> 25 years of software development and driving s/w teams, mostly
> system-level (OS, tools etc.). Have used SCC from SCCS, RCS, PVCS, VSS
> (yuck), versions of Perforce and SVN.

That's about twice my experience in all respects, so I'm _very_ glad to have
your help.

>> [you could store the bug number in a revision property]
> I agree -- but the issue is that having created this formal data svn
> doesn't really allow me to do much with it, programmatically speaking.

Hmm ... yes.

> But, really, is creating a tag, with all the branching etc needed, as
> easy as this:
> svn commit foo.c --label "DEFECT-FIX:1234"

Well, it requires two separate svn commands but it's even easier than that if
you write a script/macro/shell-function to help:

   svn-commit-fix 1234 foo.c

where svn-commit-fix is
svn commit "$@" &&
   svn copy $REPOS/trunk $REPOS/tags/DEFECT-FIX-$FIX

OK, so some things ought to be built-in, and using external scripts and
environment variables is not ideal, but I'm trying to concentrate on the
important facets of the functionality and not worry about the command-line
syntax to invoke it yet. We can easily add some built-in syntax if we think
it's important.

More important is that that method results in two commits. That is a bigger
deal, perhaps indicating that it isn't doing conceptually what you want. In
your example, the label was to be applied at the same time as the commit, but
in practice this would only sometimes be the case. At other times, the user
would apply the label later, so we shouldn't be thinking about how to combine
the two commits into one, but we do need to think about whether the action of
labelling should be a versioned event.

Do you have any views yet on whether you would want revision-alias labels to be
version-controlled, or on what the significant implications would be if they
were or weren't?

> ok, what I'm really getting at is that labels should be able to act as a
> *function* within a command-line; the return value of the label is its
> rev#, and this return value can be used *within* an svn command wherever
> a rev# is expected. Tags can *represent* a rev#, but this implied
> information can only be recovered in certain commands and only implicitly.

Well, that's really just saying that what we mean by a "label" is an alias for
a revision number, on which I think we are roughly in agreement. Unless you
mean that it should be a more general function than a simple 1-to-1 mapping?

> You mention the use of revision properties, which would indeed be a
> prefect way to handle my scenario EXCEPT that there is no way to feed
> the value of such a property back into an svn command. IMHO svn is
> crying out for a way to access properties within the command line. In
> fact, providing such a feature would in fact provide a perfectly valid
> label mechanism virtually for free, as well as any number of other
> useful enhancements.

That's an interesting idea. Would you care to start a separate mail thread
about it?

> ok, lets' see where I think we are...
> 1. I think we agree that there might be a case for some enhancements to
> relative revision numbers to handle the PRIOR or -1 case.


> 2. I'm not clear on your position wrt how the rev# of the defect
> check-in is tracked. At one point I think you're arguing that, yes, you
> *should* indeed create a tag for each such check-in.

What I was really saying is that if you want to refer to them by name rather
than number, which is your basic premise, then yes, creating a tag is the
closest you can get to your ideal in basic command-line usage at present.

> otoh you also mention the use of revision properties

What I was thinking there is that if you, as administrator, currently want to
set up a system that links Subversion to your bug tracker and provides the
easiest possible command-line experience for your users, the best way is
probably by writing scripts that store and use the bug number in a revision

> typically hundreds/thousands of defects in a medium project. Is the tool
> *really* up to managing all those tags? Are users/admins?

Another good point. No, not when they all go into one directory. A thousand
should be fine but gets slow on BerkeleyDB repositories, and some large
projects have hundreds of thousands of issues reported. Issue #2067 ("Perf
issues with BDB and directories with a large number of items") is a major
factor on BDB, but it's probably not the only problem that would make large
lists unmanageable. Of course, it might not be much easier to ensure that a
dedicated list of labels remains manageable.

This is what I think we should do next:

+ Consider various avenues that cropped up that might be useful regardless of
labelling, such as revision-number arithmetic (issue #1213) and substitution of
property values into a command. We should file issues for these as and when
they are moderately well thought out.

+ Write a detailed proposal for revision-alias labels that would cover this
simple use case, and discuss it.

+ Consider a more complex use case like the following: Each bug fix to be
tracked consists of a series of non-consecutive commits. If it is known in
advance that the fix will be complex, then that work is done on a branch, and
the result is afterwards merged to the trunk, but often a commit is made to the
trunk that aims to fix the bug, but is then seen to be incomplete and one or
more follow-ups are made, with other unrelated commits happening in between
them. We need to determine whether and how "labels" should track this situation.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 3 22:44:13 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.