You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2005/05/20 18:50:50 UTC
1.2.0 tarballs up for testing/signing
Cut from r14790 on 1.2.x branch.
http://fornix.brain.org/subversion/
-rw-rw-r-- 1 svnrm svnrm 7011017 May 20 13:42 subversion-1.2.0.tar.bz2
-rw-rw-r-- 1 svnrm svnrm 8620677 May 20 13:42 subversion-1.2.0.tar.gz
-rw-rw-r-- 1 svnrm svnrm 11459522 May 20 13:46 subversion-1.2.0.zip
md5sums:
f25c0c884201f411e99a6cb6c25529ff subversion-1.2.0.tar.bz2
ad2daf6ec0f17b84131828eca9888c98 subversion-1.2.0.tar.gz
4834a942fb7395d0f647283d6705aefd subversion-1.2.0.zip
sha1sums:
6dcafbd5a4636e9962cca06d93267028143f303d subversion-1.2.0.tar.bz2
bee1021a1dd9fedc6aae4f59395dca8610b6830a subversion-1.2.0.tar.gz
957b9881fb91da8ed12161126d25539756cc4de0 subversion-1.2.0.zip
Please test and send me your signatures. Thank you.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
!DSPAM:42839e106075237837298!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by Sigfred Håversen <bs...@mumak.com>.
Ben Reser wrote:
> Cut from r14790 on 1.2.x branch.
>
> http://fornix.brain.org/subversion/
>
>
> -rw-rw-r-- 1 svnrm svnrm 7011017 May 20 13:42 subversion-1.2.0.tar.bz2
> -rw-rw-r-- 1 svnrm svnrm 8620677 May 20 13:42 subversion-1.2.0.tar.gz
> -rw-rw-r-- 1 svnrm svnrm 11459522 May 20 13:46 subversion-1.2.0.zip
>
> md5sums:
> f25c0c884201f411e99a6cb6c25529ff subversion-1.2.0.tar.bz2
> ad2daf6ec0f17b84131828eca9888c98 subversion-1.2.0.tar.gz
> 4834a942fb7395d0f647283d6705aefd subversion-1.2.0.zip
>
> sha1sums:
> 6dcafbd5a4636e9962cca06d93267028143f303d subversion-1.2.0.tar.bz2
> bee1021a1dd9fedc6aae4f59395dca8610b6830a subversion-1.2.0.tar.gz
> 957b9881fb91da8ed12161126d25539756cc4de0 subversion-1.2.0.zip
>
> Please test and send me your signatures. Thank you.
>
Hi,
I grabbed subversion-1.2.0.tar.gz, but it does not build.
The RC2 does build and passes the regression tests. This on
OpenBSD/i386 -current, using the ports system.
I've attached a zipped output of the build. It ends with
cc -O2 -pipe -DNEON_ZLIB -DNEON_SSL -I/usr/ports/devel/subversion/w-subversion-1.2.0/subversion-1.2.0/subversion/include -I./subversion -I/usr/local/include/neon
-I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include/db4 -I/usr/local/include -o subversion/clients/cmdline/util.o -c
/usr/ports/devel/subversion/w-subversion-1.2.0/subversion-1.2.0/subversion/clients/cmdline/util.c
cd subversion/clients/cmdline && /bin/sh /usr/ports/devel/subversion/w-subversion-1.2.0/build-i386/libtool --tag=CC --silent --mode=link cc -O2 -pipe -DNEON_ZLIB
-DNEON_SSL -L/usr/local/lib/db4 -L/usr/local/lib -rpath /usr/local/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o
delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o lock-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o
propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o unlock-cmd.o update-cmd.o
util.o ../../../subversion/libsvn_client/libsvn_client-1.la ../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../subversion/libsvn_ra/libsvn_ra-1.la
../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb -lexpat -liconv
/usr/local/lib/libapr-1.la -L/usr/local/lib -lneon -lssl -lcrypto -lz -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm -lintl -liconv -lz
/usr/local/lib/libsvn_fs_fs-1.so.0.0: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libsvn_subr-1.so.0.0: warning: sprintf() is often misused, please use snprintf()
/usr/local/lib/libaprutil-1.so.0.1: warning: strcat() is almost always misused, please use strlcat()
main.o(.text+0x1c7): In function `main':
: undefined reference to `svn_ra_initialize'
collect2: ld returned 1 exit status
*** Error code 1
Hopefully it's just me making a mistake.
/Sigfred
Re: 1.2.0 tarballs up for testing/signing
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>Please test and send me your signatures. Thank you.
>
Tested all 6 combinations on Windows.
For the .zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
iQEVAwUAQpD/Iim4ktDIYoUBAQK8DAf9FoLUDOFG44lFWI9nUYl1a+G/W98meAsr
4ayd8PBe+sOaLroAqZpY1PF/rDbUZ33DaGRhLbgFO8tXrKx4zWQjucDUrD1z2kvQ
SfUrizWHOudrTTYcmfn8m6SKZQE1ULPD+YT+UEJJr4LFd4VjYkeyLe+69t60dWQ+
3vKHP/D8McooAxDmJjrmGNd05kerLI+t8rBSnA8VvaXFlv6CwTz92otG+Itj9mBP
O8fn1dSydb2USuitqZSj04V/ig2n7lAOi2XwhaZk+Tb0oIPOJ14xIGcR1UC0fatl
iaEzptqf5wsifwFEb9R1neB8E0mtjYNimvzwbU0Nph8Wa4qmx8MwoQ==
=Yo+Q
-----END PGP SIGNATURE-----
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by Max Bowsher <ma...@ukf.net>.
David Weintraub wrote:
...
> Any thoughts about labels vs. tags?
Please repost this email with a meaningful subject line.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by kf...@collab.net.
Oops :-(.
I have no objection to this thread being here, but please don't start
it as a reply to an unrelated thread. Note this is not merely a
matter of changing the Subject header. See
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
for details.
At this early stage, I would recommend restarting the thread.
Thanks,
-Karl
David Weintraub <qa...@gmail.com> writes:
> Over on the Subversion User List, there has been quite a discussion on
> the problems with "tags" and the need for a true object type called a
> "label". This discussion can be found at:
> <http://subversion.tigris.org/servlets/BrowseList?listName=users&by=thread&from=319767&to=319767&first=1&count=115>
> <http://tinyurl.com/d4ql8>
>
> After extensive debate, we felt it was time for the Subversion
> developers to get involved in our discussion.
>
> We agree that tags have several short comings:
>
> Tags are not first class objects in Subversion -- just another
> directory. It is up to the administrator to know that a particular
> directory is a tag and not a branch. This type of knowledge is stored
> in the implementation of the site and not in Subversion itself.
>
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can checkout
> the tag's directory, make modifications, then commit those changes.
> This means an admin could create a REV1.0 tag directory, and have
> users change it without the administrator's knowledge.
>
> There is also no way a tag can be used in Subversion's "svn" sub
> commands. For example, in order to compare the current version of
> foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
> version of foo elsewhere and use an external diff command, or find out
> the revision number that was used to create REV1.2, then plug that
> into the diff command. It would be much easier if you could do this:
>
> $ svn diff -rREV1.2 foo.c
>
> On the Subversion User's list, we've discussed several ways to
> implement tags which I'm not going to go through here since that is
> really up to the developers. We do agree that we'd like to see the
> following features implemented:
>
> 1). There should be a fairly easy to use "svn mklabel" command that
> creates the label.
>
> 2). Anyone should be able to create a label, but only the Subversion
> administrator should be able to change it. This would include editing
> the label, moving it, renaming it, and even deleting it.
>
> 3). You need to be able to list the various label names created.
>
> 4). Most importantly, all of the sub commands for svn and svnlook that
> take the --revision parameter must understand the concept of labels.
> That is, I should be able to specify a label rather than a revision
> number, and Subversion automatically does the right thing
>
> We also discussed several ways labels could be implemented: As a
> special property on files, as an alias to a particular revision
> number, and as a special instance of a "tag". However, we realize the
> question of how labels should be implemented is really up to the
> developers.
>
> Any thoughts about labels vs. tags?
>
> --
> David Weintraub
> qazwart@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
David Weintraub wrote:
> used Perforce, ClearCase, StarTeam, VSS, RCS, SCCS, and more version
> control systems than I care to remember. I like a lot of the basic
> concepts of Subversion, and decided to try it out at my new position
> since I was allowed to choose the VCS we got to use.
I'm glad you said this. I now know that you are very familiar with version
control concepts and so the feature that you are asking for that you call
"labels" is probably really useful. (To begin with, I thought you were a newbie.)
[...]
> However, it's still obvious that Subversion is fairly young and is
> still trying to work out a few kinks. Labels are one item. Having a
> way to find information without parsing through the log output is
> another. Being able to do a "remove version" and "remove element" is
> another [...]
Please remember, when you use words like "labels", "remove version" and "evil
twins", that you know what you mean but I don't.
By the way, you can find lots of information without parsing through the log
output.
> I'm also still working my way around Subversion. When I rename a
> file, is Subversion realy adding it and dropping it, or does
> Subversion understand renaming? If it adds and drops the file, how
> does it track history? If it allows for true renaming, does it have a
> problem with evil twins? How well does Subversion handle merging? I
> seem to have problems merging when the directory itself changes.
As you learn about Subversion you will discover the answers to most of those
questions. Then you will be able to say how the feature you want is better
than what Subversion currently provides.
I look forward to having your help.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Branko Čibej <br...@xbc.nu>.
David Weintraub wrote:
>On the user list, I mentioned that there are really two forms of
>"obliterate": One removes a particular version of a file (like
>ClearCase's "rmversion") and one that removes the entire history of a
>file (like ClearCase's "rmelem"). I consider the former to be more
>used than the latter.
>
>The problem I see is that Subversion doesn't version a particular
>file, but the entire archive. Because of this, I imagine it would be
>rather difficult to implement such commands.
>
>
That's not really the reason wny it's difficult. The main problem is
that you have to scan the whole repository for references to the file,
and do forward-tracking of history (that's not esily done with the
current repository schema).
The "rmversion" variant is even harder because you can't just remove all
references, you have to modify them.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
On 5/23/05, Branko Čibej <br...@xbc.nu> wrote:> IMHO, ClearCase's "rmelem" command is the horriblest thing in existence,> preciesly because it removes _all_ history associated with an element.> So if you do that, you've got a good chance of destroying historical> configurations. "rmversion" has similar problems, but to a lesser extent.
We never allowed users to use "rmelem" because of what you stated. Itis a very evil and dangerous command and the first thing we did in anyproject was to write a trigger to deactivate it. In theory, any userwho created an element has a right to use "rmelem" on it -- even ifother users have made changes on that element. A user could "rmelem"any element they created no matter how old it is, whether it iscurrently used or not, etc.
That said, I probably used rmelem on my repository about once permonth when a user accidentally added something that they shouldn't.
Even then, we could have simply left the extraneous element there andsimply remove references to that element from the directory. However,there has been a couple of times when someone added a file thatcontained proprietary information that should not be archived. Inthese cases, we had to scrub that file from the archive.
The "rmversion" command was used to remove binary versions of filesthat were no longer needed. Many places store their build resultsinside of ClearCase. For example, a company might store the binariesthat are shipped to QA or the version of a library that everyoneshould be using for their testing. Once these versions are no longerneeded, they are scrubbed from the archive to save room.
> That said, there have been many requests for something we like to call> "svn obliterate" which would be close to ClearCase's "rmelem". People> seem to be mostly concerned about limiting database storage> requirements, and that's a valid concern.
On the user list, I mentioned that there are really two forms of"obliterate": One removes a particular version of a file (likeClearCase's "rmversion") and one that removes the entire history of afile (like ClearCase's "rmelem"). I consider the former to be moreused than the latter.
The problem I see is that Subversion doesn't version a particularfile, but the entire archive. Because of this, I imagine it would berather difficult to implement such commands.
--David Weintraubqazwart@gmail.com
Re: Subversion "labels" vs. "tags"
Posted by Branko Čibej <br...@xbc.nu>.
David Weintraub wrote:
>On 5/23/05, Branko Čibej <br...@xbc.nu> wrote:
>
>
>>David Weintraub wrote:
>>
>>Once again, I'd like to draw attention to my proposal from a year ago:
>>
>> http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>>
>>
>>
>
>My only question would be one of protection. How would you prevent
>anyone from changing a label if its just a property?
>
>
The answers are the same as always: pre-revprop-change hook today, ACLs
someday.
>I like the proposal, and it would certainly make properties in general
>more useful since I would be allowed to actually search on them.
>
Note that the proposal is about revision properties, not properties in
general. Property indexing in generatl is another kettle of fish.
[...]
>However, it's still obvious that Subversion is fairly young and is
>still trying to work out a few kinks. Labels are one item. Having a
>way to find information without parsing through the log output is
>another. Being able to do a "remove version" and "remove element" is
>another (and I'm not even sure if this would even be possible in
>Subversion at all).
>
>
IMHO, ClearCase's "rmelem" command is the horriblest thing in existence,
preciesly because it removes _all_ history associated with an element.
So if you do that, you've got a good chance of destroying historical
configurations. "rmversion" has similar problems, but to a lesser extent.
Read the last part of my post, the one about the TimeSafe property and
how Subversion doesn't have it yet, but should. ClearCase doesn't have
it, either.
That said, there have been many requests for something we like to call
"svn obliterate" which would be close to ClearCase's "rmelem". People
seem to be mostly concerned about limiting database storage
requirements, and that's a valid concern.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
On 5/23/05, Branko Čibej <br...@xbc.nu> wrote:> David Weintraub wrote:> > Once again, I'd like to draw attention to my proposal from a year ago:> > http://svn.haxx.se/dev/archive-2004-04/0973.shtml>
My only question would be one of protection. How would you preventanyone from changing a label if its just a property?
I like the proposal, and it would certainly make properties in generalmore useful since I would be allowed to actually search on them. I'veused Perforce, ClearCase, StarTeam, VSS, RCS, SCCS, and more versioncontrol systems than I care to remember. I like a lot of the basicconcepts of Subversion, and decided to try it out at my new positionsince I was allowed to choose the VCS we got to use.
I like the idea of versioning the entire archive vs. versioningindividual files. It makes changes atomic and builds in the concept ofchange sets. I like the fact that I can use a wide variety of openstandards for the server/client communication. I like the fact thathooks are run from the server and not the client. I like the fact Idon't have to give a damn about how someone sets up their client. Theycan use an Etch-a-Sketch for all I care. That makes my life muchsimpler.
However, it's still obvious that Subversion is fairly young and isstill trying to work out a few kinks. Labels are one item. Having away to find information without parsing through the log output isanother. Being able to do a "remove version" and "remove element" isanother (and I'm not even sure if this would even be possible inSubversion at all).
I'm also still working my way around Subversion. When I rename afile, is Subversion realy adding it and dropping it, or doesSubversion understand renaming? If it adds and drops the file, howdoes it track history? If it allows for true renaming, does it have aproblem with evil twins? How well does Subversion handle merging? Iseem to have problems merging when the directory itself changes.
I'm not specifying any particular method of implementation. And, maybeI don't really understand how easy it is to use labels. Maybe it'ssimply a problem of communication. Maybe working with the tagsdirectory as a release mechanism isn't as klunky as it sounds.
--David Weintraubqazwart@gmail.com
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> Branko Čibej wrote:
>>> Once again, I'd like to draw attention to my proposal from a year ago:
>>>
>>> http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>>
>> That looks like it might be a sound basis on which to develop certain
>> sorts of features including symbolic naming of revision numbers. Can
>> you point to some use cases or a (fruitful) discussion of the need for
>> that feature?
>
> Ah. I recall there was a long thread on users@ and/or dev@ at the time,
> similar to the one we're having now.
Similar ... as in ... not fruitful? :-)
> As to use cases, I mentioned a few in the post; these are obvious:
>
> * Mnemonic labels are easier to remember than revision numbers
That's true, but it's a general reason why labels are useful in some cases, not
a "use case" which is a realistic example of using them in a particular way.
> * If you do magic with svnadmin dump/load, i.e., split or merge
> repositories, revision numbers will change, but revision labels
> will retain their meaning.
Right, good ... so a use case might be that when making a permanent reference
to a revision in a bug tracker, one would use the revision label "FIX_BUG_1234"
to refer to the revision(s) in which bug #1234 was fixed.
> * If you look at our backporting process, wouldn't it be nice if you
> could define a single mnemonic alias to all the revisions that
> need to be merged from trunk to a release branch?
Yup ... that's a good one. That's a "change set", pretty much.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> Once again, I'd like to draw attention to my proposal from a year ago:
>>
>> http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>
>
> That looks like it might be a sound basis on which to develop certain
> sorts of features including symbolic naming of revision numbers. Can
> you point to some use cases or a (fruitful) discussion of the need for
> that feature?
Ah. I recall there was a long thread on users@ and/or dev@ at the time,
similar to the one we're having now.
As to use cases, I mentioned a few in the post; these are obvious:
* Mnemonic labels are easier to remember than revision numbers
* If you do magic with svnadmin dump/load, i.e., split or merge
repositories, revision numbers will change, but revision labels
will retain their meaning.
* If you look at our backporting process, wouldn't it be nice if you
could define a single mnemonic alias to all the revisions that
need to be merged from trunk to a release branch?
Indexing by revprop would be a great way to integrate, for example, a
bug tracking system with Subversion. Currently there's a de-facto
standard that puts bugtrack info into the log message, but it would be
better if you had (indexed) revision propertie for that.
Etc.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Once again, I'd like to draw
> attention to my proposal from a year ago:
>
> http://svn.haxx.se/dev/archive-2004-04/0973.shtml
That looks like it might be a sound basis on which to develop certain sorts of
features including symbolic naming of revision numbers. Can you point to some
use cases or a (fruitful) discussion of the need for that feature?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Branko Čibej <br...@xbc.nu>.
David Weintraub wrote:
>On 23 May 2005 12:32:17 -0500, C. Michael Pilato <cm...@collab.net> wrote:
>
>
>>David Weintraub <qa...@gmail.com> writes:
>>
>>
>>
>>>Once a tag is created, there is no real mechanism built into
>>>Subversion that protects the sanctity of that tag. A user can
>>>checkout the tag's directory, make modifications, then commit those
>>>changes. This means an admin could create a REV1.0 tag directory,
>>>and have users change it without the administrator's knowledge.
>>>
>>>
>>Well, to be clear, it may be changed in a way that doesn't draw the
>>administrator's attention, but not in a way that can elude an
>>administrator's ability to determine that change has happened.
>>
>>
>
>Yes, that's correct. However, unless the administrator is vigilant and
>checks for changes in the tag every time before it is used, it is very
>easy for this to happen.
>
Not if you configure an appropriate pre-commit hook that forbits
modifications on tags.
[...]
>>I would discourage the use of labels on anything but whole revisions.
>>
>>
>
>The drawback to this is that a label could not be used to mark what
>files were actually in a release since the label would apply to all
>files in the entire archive. If I had multiple projects in a single
>archive and I created a label REV1.2, I'd end up marking all projects
>with that label even if it doesn't apply to them. An important part of
>labeling is not just labeling what version of the files, but which
>files belong to a particular label.
>
>Plus, you have to change the Subversion archive format yet again to
>implement this feature.
>
>
We'd have to do that anyway to get what you want, but the changes for
per-revision labels would be a lot smaller. Once again, I'd like to draw
attention to my proposal from a year ago:
http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>Not being able to specify what files were in a particular release is
>one of the reasons we discussed a label as being very much like a tag,
>but with a few special features:
>
>* A mklabel command does a URL copy to a special label directory much
>like a "URL copy does. It's atomic, fast, and you can specify what
>files and directories.
>
>
This gains you nothing with regard to tag copies, except the "special
label directory" thing which is agains Subversion's design principles;
in this case, the one about SVN not defining repository layout policy.
>* Subversion would understand that you cannot commit to a label
>directory any changes unless you do it via a file:// URL. This way,
>you could prevent a typical user from making any changes, yet still
>allow the administrator full control over the archive and label.
>
>
This can be acheived either via a pre-commit hook (which works today),
or with in-repository ACLs (which will be added one of these days). And
making file:// an exception would be a very bad idea indeed. The only
allowable exception should be server-side administrative tools
(svnadmin, to be precise).
>* Subversion would understand that using the --revision parameter may
>mean you're refering not to the current working directory, but to the
>file located somewhere under the special label directory.
>
>
I've yet to see someone explain how this would work in practice without
creating confusion. The --revision option defines a revision, not a
path, and an exception like this seems weird. Not just for the
command-line client, GUIs would have to deal with this inconsistency, too.
>The upside to this is that it doesn't require the Subversion archive
>format to be changed,
>
How did you arrive at that conclusion? You're special-caseing a
directory that hadn't been special-cased before.
>The third method involves properties. You could use a special property
>to mark the versions of the files you want to label with the label you
>want. Then, add a needed feature in Subverison that allows you to
>search based upon property.
>
>
Which implies a change in the database schema again.
>The plus side is that we get a very useful new feature in Subversion
>(search on property) and it doesn't involve any new data types or
>resturcturing the archive. The downside is figuring how to protect the
>label file property and labeling not necessarily being an atomic
>operation.
>
>
I see lots of problems with your proposal, and don't see a single
benefit except for some syntactic sugar on the command line, which you
can already acheive through normal shell tools.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
On 23 May 2005 12:32:17 -0500, C. Michael Pilato <cm...@collab.net> wrote:
> David Weintraub <qa...@gmail.com> writes:
>
> > Once a tag is created, there is no real mechanism built into
> > Subversion that protects the sanctity of that tag. A user can
> > checkout the tag's directory, make modifications, then commit those
> > changes. This means an admin could create a REV1.0 tag directory,
> > and have users change it without the administrator's knowledge.
>
> Well, to be clear, it may be changed in a way that doesn't draw the
> administrator's attention, but not in a way that can elude an
> administrator's ability to determine that change has happened.
Yes, that's correct. However, unless the administrator is vigilant and
checks for changes in the tag every time before it is used, it is very
easy for this to happen. More likely, something will be "released"
into the field, someone will realize something is wrong, the
Administrator checks, and discovers that someone had committed changes
to the tag directory. Lots of yelling and screaming ensues as the
Finger 'o Blame slowly spins round and round.
> > We also discussed several ways labels could be implemented: As a
> > special property on files, as an alias to a particular revision
> > number, and as a special instance of a "tag". However, we realize the
> > question of how labels should be implemented is really up to the
> > developers.
> I would suggest allowing the setting of multiple labels per revision.
Of course! My build #12383 will become QA's release 1.23.3 which will
released to the customer as revision 1.3 and probably sold as
WidgetSet 2005. I'd need to keep track of all of these labels. (And
while we're busy day dreaming here, why not some way to say that these
labels are actually related? Something you don't have in other version
control systems)
> I would discourage the use of labels on anything but whole revisions.
The drawback to this is that a label could not be used to mark what
files were actually in a release since the label would apply to all
files in the entire archive. If I had multiple projects in a single
archive and I created a label REV1.2, I'd end up marking all projects
with that label even if it doesn't apply to them. An important part of
labeling is not just labeling what version of the files, but which
files belong to a particular label.
Plus, you have to change the Subversion archive format yet again to
implement this feature.
Not being able to specify what files were in a particular release is
one of the reasons we discussed a label as being very much like a tag,
but with a few special features:
* A mklabel command does a URL copy to a special label directory much
like a "URL copy does. It's atomic, fast, and you can specify what
files and directories.
* Subversion would understand that you cannot commit to a label
directory any changes unless you do it via a file:// URL. This way,
you could prevent a typical user from making any changes, yet still
allow the administrator full control over the archive and label.
* Subversion would understand that using the --revision parameter may
mean you're refering not to the current working directory, but to the
file located somewhere under the special label directory.
The upside to this is that it doesn't require the Subversion archive
format to be changed, and users with older Subversion clients would
still be able to access the labels. You could even access them via a
web browser if you're using httpd. You get all of the features needed
to implement labels.
The downside to this is it is much more difficult to implement and
there are questions on how would things be handled (when I do a "svn
diff -rREL1.2 foo.c", how would Subversion know where "foo.c" lives
inside the label REL1.2?). Plus, as one person pointed out, what would
happen if I did want to label everything across the archive? REV1.2
would also label the REV1.0 files (since they're stored on a label
branch. When REV1.3 comes out, REV1.2 and REV1.0 would get labeled yet
again. Someone downloading the entire archive could end up with
several hundred tetrabytes of data.
The third method involves properties. You could use a special property
to mark the versions of the files you want to label with the label you
want. Then, add a needed feature in Subverison that allows you to
search based upon property.
The plus side is that we get a very useful new feature in Subversion
(search on property) and it doesn't involve any new data types or
resturcturing the archive. The downside is figuring how to protect the
label file property and labeling not necessarily being an atomic
operation.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Weintraub <qa...@gmail.com> writes:
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can
> checkout the tag's directory, make modifications, then commit those
> changes. This means an admin could create a REV1.0 tag directory,
> and have users change it without the administrator's knowledge.
Well, to be clear, it may be changed in a way that doesn't draw the
administrator's attention, but not in a way that can elude an
administrator's ability to determine that change has happened.
> We also discussed several ways labels could be implemented: As a
> special property on files, as an alias to a particular revision
> number, and as a special instance of a "tag". However, we realize the
> question of how labels should be implemented is really up to the
> developers.
I would discourage the use of labels on anything but whole revisions.
I would suggest allowing the setting of multiple labels per revision.
And I would avoid using properties for the storage format -- make the
labels a first-class data object.
- Add a new 'labels' table which maps labels to revisions
- Possibly add a reverse mapping, though only if folks need to ask
"What labels are associate with revision REV?"
- Give the RA layers and repos layer a "label-to-rev" lookup
routine.
Done deal, right?
We could probably even do this in the 1.x line, soft-upgrading
repositories to make the new table, making the new RA layer gracefully
fail when the server doesn't support the new lookup...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
David Weintraub wrote:
> Over on the Subversion User List, there has been quite a discussion on
> the problems with "tags" and the need for a true object type called a
> "label". This discussion can be found at:
> <http://subversion.tigris.org/servlets/BrowseList?listName=users&by=thread&from=319767&to=319767&first=1&count=115>
> <http://tinyurl.com/d4ql8>
>
> After extensive debate, we felt it was time for the Subversion
> developers to get involved in our discussion.
Maybe it is, but you cannot make a worthwhile argument without acknowledging
the existing way of doing tags and saying what is deficient about it. In the
rest of your message, you do not do so.
I give some brief examples of the existing way below, just to show where you
need to make your arguments.
> We agree that tags have several short comings:
>
> Tags are not first class objects in Subversion -- just another
> directory. It is up to the administrator to know that a particular
> directory is a tag and not a branch. This type of knowledge is stored
> in the implementation of the site and not in Subversion itself.
Agreed. This may cause problems in some respects (but how, exactly?) while it
has advantages in other respects.
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can checkout
> the tag's directory, make modifications, then commit those changes.
> This means an admin could create a REV1.0 tag directory, and have
> users change it without the administrator's knowledge.
Well, that behaviour is not built into the core program or active by default:
the administrator needs to set it up by installing an appropriate hook script.
Again, this can be seen as a shortcoming or as flexibility depending on one's
point of view.
> There is also no way a tag can be used in Subversion's "svn" sub
> commands.
Wrong.
> For example, in order to compare the current version of
> foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
> version of foo elsewhere and use an external diff command, or find out
> the revision number that was used to create REV1.2, then plug that
> into the diff command.
Wrong. You can do:
TAGS="http://blah.blah/repos/tags"
svn diff --old=$TAGS/1.2 --new=. foo.c
I'm not saying that's as simple as you want it to be, just that you have to
acknowledge it and analyse what is unacceptable about it if you think it is
unacceptable.
> It would be much easier if you could do this:
>
> $ svn diff -rREV1.2 foo.c
OK, so maybe we can work towards providing something more like that.
> On the Subversion User's list, we've discussed several ways to
> implement tags which I'm not going to go through here since that is
> really up to the developers. We do agree that we'd like to see the
> following features implemented:
>
> 1). There should be a fairly easy to use "svn mklabel" command that
> creates the label.
There is such a command, though it's called "copy" not "mklabel":
svn copy <whatever-you-want-to-label> $TAGS/1.2
e.g.
svn copy . $TAGS/1.2
or
svn copy http://blah.blah/repos/trunk $TAGS/1.2
>
> 2). Anyone should be able to create a label, but only the Subversion
> administrator should be able to change it. This would include editing
> the label, moving it, renaming it, and even deleting it.
Well, that may be the policy that you personally want today, but other
administrators might want to allow certain users to modify tags, at least for
some types of modification such as rename and delete. That's why the current
way of doing it is that the administrator sets the policy by choosing a
suitable pre-commit hook script.
>
> 3). You need to be able to list the various label names created.
Easy:
svn list $TAGS
>
> 4). Most importantly, all of the sub commands for svn and svnlook that
> take the --revision parameter must understand the concept of labels.
Well, all of them can access tags, as I demonstrated with "diff" above.
Whether they need to "understand the concept" is another question, and it is
for you to say why they should.
> That is, I should be able to specify a label rather than a revision
> number, and Subversion automatically does the right thing
Well, you can specify a tag instead of a revision number, although not in the
same syntax, and as I admitted above it may not be as simple as you would like.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Weintraub <qa...@gmail.com> writes:
> Is there another way to use "switch"? Can I simply "switch" just a few
> files and not my whole working directory?
Yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Brad Appleton <br...@gmail.com>.
David Weintraub wrote:
> Brad Appleton has brought up an interesting point in that there are
> maybe two separate concepts of labels/tags. Brad points out that there
> is labeling for marking files and their versions for a particular
> release vs. labeling as an alias for a configuration created by the
> version control system. In that case, the argument could be made that
> a lookup table for labels vs. revision numbers is really the way to
> implement labels, and that "tags" should be used when a user wants to
> mark a particular release.
Thanks David! I thought of another way to describe the difference
between the two.
* A "revision alias" is a binding of a name to an existing
configuration's identifier
* A "label" is creating a (possibly evolving) configuration and it's
identifier
Another potentially interesting thought is that, given the above, a
"label" may be used as a branch-point. A revision-alias may not.
Sometimes it helps me to think of differences between what varies and
what stays the same.
* With a revision-alias, if I missed something I really should have
included, I "commit" a new configuration, and I move the binding of the
existing name from the previous revno to the new revno.
* With a label implemented using "copy", if I missed something I really
should have included, I commit a new configuration, and the "name"
automatically tracks with the new "latest/current" configuration.
In other words, if I need to make the name refer to a revised/corrected
"configuration", then:
- with a revision-alias, I keep the same name and change which
configuration it is bound to.
- with a "label, I keep the binding between the name and the copy, and I
change the content of the copy.
One approach keeps the "content" the same and varies the context; the
other approach keeps the "context" and varies the content.
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
On 5/24/05, Julian Foad <ju...@btopenworld.com> wrote:
> David Weintraub wrote:
> [...]
> > Is there another way to use "switch"? Can I simply "switch" just a few
> > files and not my whole working directory?
>
> Yes, and yes. You just specify the files and/or directories that you want to
> switch as arguments to the command.
I just tried "switching" a single file in a working directory. It
replaced my file with a directory of a similar name, then downloaded
the "switched" URL into it.
I'm going to have to play around with it a bit more. The various books
I have simply cover "switching" as a way to branch. I'll take this
part of the conversation to the user's list.
> If you will now agree that the concept that you call a "label" is the same as
> the concept that Subversion developers call a "tag", then we seem to have
> arrived at a shared view. (The need to set up hook scripts and use awkward
> syntax in order to use tags in Subversion is part of the implementation and
> user interface, not the concept.)
>
> Now we need to see in what respects the use is _too_ awkward at present, and in
> what respects it is just a little awkward but could be made better anyway, and
> then we could see about improving it.
That's one of the arguments for simply using tags as the basis for
"labels". The problem is with the syntax. I should be able to replace
any reference to a revision number with a label. All Subversion
commands should be able to understand this. For example:
$ svn update -r 1233 foo.c #Currently allowed
versus
$ svn update -rREV1.0 foo #What we would like
--------------------------
$ svn diff -r 1233:2323 foo.c #Currently allowed
versus
$ svn diff -r REV1.0:REV1.2 foo.c #What we would like
This is a feature found in almost every single version control system
with a command line interface. If you can find a way to use tags with
this type of syntax, you'll make a lot of Subversion users very
happy..
The two other items are minor compared to this: An easier "make label"
syntax instead of the URL copy, and Subversion understanding that
labels/tags should be "difficult" to modify. I can write a simple
shell script for the first one (which then has to be installed on all
client systems), and I can write a hook for the second one (although
such behavior is usually built into almost all Configuration
Management system).
Brad Appleton has brought up an interesting point in that there are
maybe two separate concepts of labels/tags. Brad points out that there
is labeling for marking files and their versions for a particular
release vs. labeling as an alias for a configuration created by the
version control system. In that case, the argument could be made that
a lookup table for labels vs. revision numbers is really the way to
implement labels, and that "tags" should be used when a user wants to
mark a particular release.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Brad Appleton <br...@gmail.com>.
David Weintraub wrote:
> Making labels synonyms for revision numbers would probably accomplish
> 90% of what is needed for labels (and with the use of tags and hooks,
> we could do the rest). However, in all other version control systems,
> you can choose what to tag. If I have four separate projects in my
> repository, I may only want to label the flies in only one of those
> projects. If labels are synonyms for revision numbers, putting a label
> would mark all of my projects.
Julian Foad wrote:
> OK, so you don't want a "label" to just mark a point in time, you want
> it to mark a set of particular versions of particular files. So the
> concept is the same as Subversion's "tags"; it's just the useability
> that bothers you.
>
> If you will now agree that the concept that you call a "label" is the
> same as the concept that Subversion developers call a "tag", then we
> seem to have arrived at a shared view.
I think that labels/tags and revision-aliases are different things that
may indeed have some overlapping uses but which ulitimately serve
different purposes:
* I use labels to define my own configurations to the VC tool: when I
want to define the configuration, including the set of things in it as
well as the set of versions of those things, I use a label. And I give
it a meaningful name.
* I use aliases to reference configurations that were automatically
defined for me by the VC tool: when the version-control tool
automatically tracks the state after each commit, and assigns it a
number, and when I want to associate a meaningful name with that, I use
a revision-alias
In a nutshell:
- a label is "call by value" (or by "copy")
- a revision-alias is "call by name" (or by "reference")
aliases are references to an immutable configuration. I can change the
reference, but I cannot change the content it references. If I need the
same name to refer to a subsequent configuration, I dont change the
definition of the configuration, I reference a subsequent configuration
with the same name (thereby "moving" the reference)
aliases also need not create any nodes/copies in the directory tree, for
that is not their purpose. They are an alternate lookup-name, they arent
intended to be the same as immutable copies with all the semantics
that go with it (e.g., versioning).
I would use aliases (rather than labels) for things like "checkpoints",
or to capture the current "blessed" configuration (e.g., a floating
label). I would not be inclined to use them to establish formal
baselines that I would eventually freeze. I would be inclined to use
labels to establish formal baselines that I then freeze once they are
"baselined" (blessed).
Several folks seem to be equating "copies" and "aliases" as different
implementations of the "same solution/feature". I think they are not the
same or equivalent solution/feature/ I think they do different things
associated with different purposes. And while it is true some of the
effects of each are the same, each has effects that are different from
the other, and those effects are what would make me choose one over the
other in a given situation.
Someone was concerned about "revision aliases" not being clear about
which portion of the repository they reference. I think that, based on
the above, it would be very clear. The revision alias is no more, and no
less "global" then the revision-number. Anywhere you could use the
fully-qualified revision-number, the "alias" would mean the exact same
thing. Anywhere you could use the unqualified global revision number,
the alias would mean the _exact_ same thing. It's simply a lookup that
adds an extra-level of indirection to "macro expand" to a revision number.
That's my $0.02
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
(below...)
Julian Foad wrote:
> 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
> [[[
> #!/bin/sh
> REPOS=http://...
> FIX=$1
> shift
> 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.
>
>
> Yes.
>
>> 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 property.
>
>> 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.
I agree with this. I'm going to go off-line for a few days and work this
up, and will then re-post here.
--Tim
>
> - Julian
>
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
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
[[[
#!/bin/sh
REPOS=http://...
FIX=$1
shift
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.
Yes.
> 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
property.
> 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
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
Comments inline...
Julian Foad wrote:
> Tim Hill wrote:
>
>> ok, let's consider patch propogation.
>
>
> Cool. Thanks for taking the time to present this use case.
>
> Now, as usual, I'm going to go through it and comment. Well, OK, I'm
> going to push the case for the present Subversion tags mechanism a
> bit, but I think I need to push a bit in order to draw out a good
> argument from you. :-) I hope you don't mind.
Of course not -- it forces me to justify things to myself as I create
the case. Good dialog :)
>
> Oh, and let me make it clear that I don't necessarily think
> revision-alias labels are a bad idea; I'm still just trying to fully
> understand the rationale for them.
>
> By the way, I don't know, but it might help a bit to know what your
> background is. For example, are you accustomed to some particular
> version control system other than Subversion, or do you have wide
> experience, or what? One thing that makes me wonder is in the next
> sentence where you refer to your mainline build as the "main branch";
> if you were accustomed to Subversion you would have called it the
> "trunk".
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. And just so you know, I consider
SVN to be the best I've yet seen, which is why I'm pushing to fill what
few holes I see in the product :) The "main" thing comes from a large
nameless s/w company, but I chose it on purpose to try to abstract away
from svn-specific stuff.
>
>> I have a mainline build ("main" branch) and a release branch ("rel1")
>> that just takes bug fixes for a released version of the product. The
>> mainline undergoes cycles of dev/test/stabilize, and at each
>> stabilization point a "stable" tag is created so that the last stable
>> build is easily accessible.
>
>
> OK, I imagine that's a common scenario.
>
>> A bug is found in the mainline in "foo.c". It is tracked in a defect
>> tool, fixed in the mainline, checked-in, and undergoes the normal
>> dev/test/stabilize process. Product support then decides that the bug
>> is serious enough that it should be fixed in the "rel1" branch also,
>> ready for the 1.1 release.
>
>
> OK.
>
>> How do I merge the fix into the "rel1" branch? Specifically, which
>> revisions off the mainline do I compare to get the changes necessary
>> to push into "foo.c" in the "rel1" branch?
>>
>> There are actually four points in time that are significant (working
>> backwards):
>> [1] The rev# of the latest stable build of the mainline branch. Call
>> this rev# STABLE.
>> [2] The rev# where the fix to "foo.c" was checked into the mainline
>> (that is, when the defect was marked as fixed). Call this rev# FIXED.
>> [3] The rev# where the last change to "foo.c" was made prior to
>> FIXED. Call this rev# PREFIXED.
>> [4] The rev# where "rel1" was branched off of the mainline. Call this
>> rev# REL1.
>>
>> What I want to merge into the head of "rel1" is: DIFF foo.c -r
>> PREFIXED:FIXED. However I also need to examine DIFF foo.c -r
>> REL1:PREFIXED to make sure that the fix does not depend upon changes
>> made to foo.c between REL1 and PREFIXED. Note that I cannot take DIFF
>> -r PREFIXED:STABLE since other changes may have occurred in foo.c
>> between FIXED and STABLE (I'm assuming "rel1" has its own
>> testing/stabilization cycle).
>
>
> OK.
>
>> How do I locate and use the various rev# values needed? STABLE is
>> available in the "stable" tag noted above, so that's easy (but not
>> much use in this scenario).
>>
>> Neither FIXED not PREFIXED are available via tagging.
>
>
> Well, that depends whether you tagged them! (Actually I wouldn't
> expect you to have tagged PREFIXED - see below - but you suggest below
> that you would have labeled FIXED if you had labels, so I suggest you
> would have tagged it if you only have tags.)
Really? see below.
>
>> Assuming I'm using the recommended best practice of marking defect #s
>> in the message log, I will need to manually examine the log to
>> extract the rev# from the log messages.
>
>
> Well, actually what you need to do is find the revision number in
> which the fix was made, if you haven't tagged it. To find the
> revision number, you could look through the log messages, or perhaps
> you can look in your bug tracker, or perhaps you have it in a revision
> property as I mention under your point (b) below. In this project we
> try to close bugs in the issue tracker with a comment like "Fixed in
> r1234.", so the information is fairly easy to find manually.
>
>> REL1 is available via the --stop-on-copy switch, but this is not
>> available in the DIFF or MERGE commands, only LOG. So , again, I have
>> to do a manual scan of the log to obtain the rev#.
>
>
> Again, you only have to do a manual scan if you haven't tagged it. I
> would expect that you would have tagged it. At the time when you
> started your "rel1" branch you would have done:
>
> svn copy . $BRANCHES/rel1 # start a "rel1" branch
> svn copy $BRANCHES/rel1 $TAGS/rel1-start # label your "rel1" starting
> point
>
> and then you would start to modify the "rel1" branch, and you would
> tag various release candidates ("rel1-rc1" or whatever) along the road
> towards finishing it. When finished, you would tag the final version
> of it ("rel1") and delete the branch.
>
> svn checkout $BRANCHES/rel1
> # modify stuff; it seems stable enough to release
> svn cp . $TAGS/rel1-rc1 # tag a release candidate
> # now it's been tested and is definitely stable and complete
> svn copy . $TAGS/rel1 # tag the final version of it
> svn delete $BRANCHES/rel1 # the branch is no longer
> needed
>
> At least that's roughly how we do it in this Subversion project.
> Actually, we haven't been tagging the start of the branch, but we
> could and would do if we found it useful.
>
>> This is a lot of work for what is not an unusual scenario. How can it
>> made less manual (read: less error-prone)?
>
>
>> (a) I could add lots of tags. If FIXED was available as a tag, that
>> would work. But creating a tag for *every* defect fix seems
>> excessive, even if tags are cheap. And who will remember to do this?
>
>
> Umm... it'll be fun to see if you can convince us that the same
> comments don't apply to revision-alias labels :-)
>
>> More importantly, how do I locate PREFIXED? This is a *relative* rev#
>> and is conceptually related to the COMMITTED rev#, but with an
>> arbitrary starting point.
>
>
> Actually, this is easy if you are working with actual revision numbers
> either manually or in a programming/scripting language: you can just
> subtract 1. You can see that this is correct by thinking about the
> difference between foo.c in revision PREFIXED and revision (FIXED-1):
> by definition, there is no difference.
hehe -- absolutely right, you got me on that! Serves me right for
writing an email late at night.
>
> If you are working with a tag, then you can't at present get
> Subversion to calculate the previous revision for you. That is a
> deficiency which I admit is important in this scenario.
>
> There was a proposal for adding a syntax for doing this within the
> revision-number argument: something like "-rHEAD-1" or
> "-r{2005-05-31}-1" would mean the previous version of the item before
> the version in HEAD or the specified date, and "-rBLAH-2" would mean 2
> versions of the item before BLAH (which is different from the revision
> number that is 2 less than "-rBLAH"). The proposal was quite well
> developed - not far from being committable - but it didn't get
> finished or approved or whatever. We might want to ressurect it.
>
> I'm not sure whether that proposal would allow you to get the version
> that came before a particular tag. It might, something like:
> "$TAGS/rel1-start/foo.c -rHEAD-1".
>
> Anyway, I concede that there is definitely missing functionality here,
> and I don't think this has been mentioned before in this discussion so
> thank you for bringing this point to light.
I did discuss this in a thread on the users forum. Off topic, I do feel
that the svn database contains a log of valuable information (and could
contain more) that is currently difficult to mine because of limitations
in the representation of revisions to the toolchain.
>
>
>> (b) I could create a script to do the necessary SVN LOG scan, pluck
>> out the rev#, and paste it into a DIFF/MERGE command. This could work
>> for FIXED, but not PREFIXED.
>
>
> Actually it does work for PREFIXED, by subtracting 1 from FIXED.
ok, don't rub it in!!! :)
>
>> And it depends upon well-formatted log file messages, and
>> "prayer-based parsing" common to semi-formal data sets.
>
>
> Yes. Similarly the script could get the information from a dedicated
> "bug number" revision property (look up "revision properties" in the
> Subversion book if this doesn't make sense), or from your bug
> tracker. Either of those could give you the information in a more
> formal structure.
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.
>
>> (c) Use mnemonic labels for revisions, and a convention that creates
>> a label named "DEFECT-FIX:nnnn" for appropriate check-ins.
>
>
> Right! Now, why don't your arguments above about tags apply equally
> to this? You said:
>
> "But creating a tag for *every* defect fix seems excessive, even if
> tags are cheap. And who will remember to do this?"
>
> I say: Creating a tag or a label for every defect only seems excessive
> if you think the creation is an expensive operation or if the list of
> them is going to make it hard to find other kinds of tags/labels.
> Creation (of a tag) is not expensive, and to keep from cluttering your
> list of release tags (say), you can use a separate tag name space -
> e.g. "$TAGS/bugs/..." (This begs the question of whether the "labels"
> mechanism would want such a namespace mechanism.)
But, really, is creating a tag, with all the branching etc needed, as
easy as this:
svn commit foo.c --label "DEFECT-FIX:1234"
???
Or, better yet, just using a generic property switch (below).
>
> As for remembering to do it, well, what's there's no difference
> between remembering to create a tag and remembering to create a
> label. Presumably you would automate it.
>
>> Now FIXED is *directly* accessible to me *and* the toolchain.
>
>
> It appears to me that it would be accessible to the "svn" command via
> the "-r" option argument rather than via a normal non-option
> argument. Is that all you mean by "directly"?
>
> Perhaps I'm being unreasonably hard on you. I can see that there is
> some fairly profound respect in which identifying a marked point in
> history by path (a tag) is different from identifying it by revision
> (a label) ... I just don't know what the implications of this
> difference are.
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.
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.
>
>> This leaves PREFIXED up in the air, however.
>
>
> Addressed above.
>
>
>> So, my ideal is the command:
>>
>> svn diff foo.c --revision PRIOR:!DEFECT-FIX:1234
>>
>> Or something like it. Here I'm using "!" to indicate a rev# expressed
>> as a label (insert your own syntax here), and am assuming PRIOR means
>> "the last time this item was changed" (like COMMITTED but relative to
>> the other rev#).
>
>
> OK. The tags version of that command would be something like:
>
> svn diff $TAGS/DEFECT-FIX-1234/foo.c --revision HEAD-1:HEAD
>
> (The syntax "HEAD-1" or "PRIOR" is not supported yet, but that seems
> to be equally necessary for either approach.)
>
>> Skipping the ugly syntax and some significant issues around the
>> semantics/implementation of PRIOR, I think this is a significant
>> improvement over manually scanning logs.
>
>
> It seems to me that the syntax and the ability to specify one revision
> relative to another are perhaps some of the most important issues
> here. However, you are certainly bringing out some interesting points
> and helping us to understand the issue. Thanks for your continuing
> patience in working through this.
>
> - Julian
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. otoh you also
mention the use of revision properties (yes, I'm well aware of the
property system in svn -- a feature I very much like). There are
typically hundreds/thousands of defects in a medium project. Is the tool
*really* up to managing all those tags? Are users/admins?
>
>
>>> Julian Foad wrote:
>>>
>>>> Tim Hill wrote:
>>>>
>>>>> Yes, this is certainly one way. The main objection I have to the
>>>>> current scheme is that tags are just a convention, and as a result
>>>>> the toolchain cannot use the implied REV# information directly --
>>>>> it has to be manually imputed by a user and translated by him/her
>>>>> to a REV# for consumption by the toolchain. This makes
>>>>> scripting/automation difficult for some common SVN operations and
>>>>> adds burden to the dev process.
>>>>
>>>>
>>>> Please give an example (stating the desired task and showing actual
>>>> commands for doing it) of a situation in which the user has to do
>>>> this "translation".
>>>
>
>
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Tim Hill wrote:
> ok, let's consider patch propogation.
Cool. Thanks for taking the time to present this use case.
Now, as usual, I'm going to go through it and comment. Well, OK, I'm going to
push the case for the present Subversion tags mechanism a bit, but I think I
need to push a bit in order to draw out a good argument from you. :-) I hope
you don't mind.
Oh, and let me make it clear that I don't necessarily think revision-alias
labels are a bad idea; I'm still just trying to fully understand the rationale
for them.
By the way, I don't know, but it might help a bit to know what your background
is. For example, are you accustomed to some particular version control system
other than Subversion, or do you have wide experience, or what? One thing that
makes me wonder is in the next sentence where you refer to your mainline build
as the "main branch"; if you were accustomed to Subversion you would have
called it the "trunk".
> I have a mainline build ("main"
> branch) and a release branch ("rel1") that just takes bug fixes for a
> released version of the product. The mainline undergoes cycles of
> dev/test/stabilize, and at each stabilization point a "stable" tag is
> created so that the last stable build is easily accessible.
OK, I imagine that's a common scenario.
> A bug is found in the mainline in "foo.c". It is tracked in a defect
> tool, fixed in the mainline, checked-in, and undergoes the normal
> dev/test/stabilize process. Product support then decides that the bug is
> serious enough that it should be fixed in the "rel1" branch also, ready
> for the 1.1 release.
OK.
> How do I merge the fix into the "rel1" branch? Specifically, which
> revisions off the mainline do I compare to get the changes necessary to
> push into "foo.c" in the "rel1" branch?
>
> There are actually four points in time that are significant (working
> backwards):
> [1] The rev# of the latest stable build of the mainline branch. Call
> this rev# STABLE.
> [2] The rev# where the fix to "foo.c" was checked into the mainline
> (that is, when the defect was marked as fixed). Call this rev# FIXED.
> [3] The rev# where the last change to "foo.c" was made prior to FIXED.
> Call this rev# PREFIXED.
> [4] The rev# where "rel1" was branched off of the mainline. Call this
> rev# REL1.
>
> What I want to merge into the head of "rel1" is: DIFF foo.c -r
> PREFIXED:FIXED. However I also need to examine DIFF foo.c -r
> REL1:PREFIXED to make sure that the fix does not depend upon changes
> made to foo.c between REL1 and PREFIXED. Note that I cannot take DIFF -r
> PREFIXED:STABLE since other changes may have occurred in foo.c between
> FIXED and STABLE (I'm assuming "rel1" has its own testing/stabilization
> cycle).
OK.
> How do I locate and use the various rev# values needed? STABLE is
> available in the "stable" tag noted above, so that's easy (but not much
> use in this scenario).
>
> Neither FIXED not PREFIXED are available via tagging.
Well, that depends whether you tagged them! (Actually I wouldn't expect you to
have tagged PREFIXED - see below - but you suggest below that you would have
labeled FIXED if you had labels, so I suggest you would have tagged it if you
only have tags.)
> Assuming I'm using
> the recommended best practice of marking defect #s in the message log, I
> will need to manually examine the log to extract the rev# from the log
> messages.
Well, actually what you need to do is find the revision number in which the fix
was made, if you haven't tagged it. To find the revision number, you could
look through the log messages, or perhaps you can look in your bug tracker, or
perhaps you have it in a revision property as I mention under your point (b)
below. In this project we try to close bugs in the issue tracker with a
comment like "Fixed in r1234.", so the information is fairly easy to find manually.
> REL1 is available via the --stop-on-copy switch, but this is not
> available in the DIFF or MERGE commands, only LOG. So , again, I have to
> do a manual scan of the log to obtain the rev#.
Again, you only have to do a manual scan if you haven't tagged it. I would
expect that you would have tagged it. At the time when you started your "rel1"
branch you would have done:
svn copy . $BRANCHES/rel1 # start a "rel1" branch
svn copy $BRANCHES/rel1 $TAGS/rel1-start # label your "rel1" starting point
and then you would start to modify the "rel1" branch, and you would tag various
release candidates ("rel1-rc1" or whatever) along the road towards finishing
it. When finished, you would tag the final version of it ("rel1") and delete
the branch.
svn checkout $BRANCHES/rel1
# modify stuff; it seems stable enough to release
svn cp . $TAGS/rel1-rc1 # tag a release candidate
# now it's been tested and is definitely stable and complete
svn copy . $TAGS/rel1 # tag the final version of it
svn delete $BRANCHES/rel1 # the branch is no longer needed
At least that's roughly how we do it in this Subversion project. Actually, we
haven't been tagging the start of the branch, but we could and would do if we
found it useful.
> This is a lot of work for what is not an unusual scenario. How can it
> made less manual (read: less error-prone)?
> (a) I could add lots of tags. If FIXED was available as a tag, that
> would work. But creating a tag for *every* defect fix seems excessive,
> even if tags are cheap. And who will remember to do this?
Umm... it'll be fun to see if you can convince us that the same comments don't
apply to revision-alias labels :-)
> More
> importantly, how do I locate PREFIXED? This is a *relative* rev# and is
> conceptually related to the COMMITTED rev#, but with an arbitrary
> starting point.
Actually, this is easy if you are working with actual revision numbers either
manually or in a programming/scripting language: you can just subtract 1. You
can see that this is correct by thinking about the difference between foo.c in
revision PREFIXED and revision (FIXED-1): by definition, there is no difference.
If you are working with a tag, then you can't at present get Subversion to
calculate the previous revision for you. That is a deficiency which I admit is
important in this scenario.
There was a proposal for adding a syntax for doing this within the
revision-number argument: something like "-rHEAD-1" or "-r{2005-05-31}-1" would
mean the previous version of the item before the version in HEAD or the
specified date, and "-rBLAH-2" would mean 2 versions of the item before BLAH
(which is different from the revision number that is 2 less than "-rBLAH").
The proposal was quite well developed - not far from being committable - but it
didn't get finished or approved or whatever. We might want to ressurect it.
I'm not sure whether that proposal would allow you to get the version that came
before a particular tag. It might, something like: "$TAGS/rel1-start/foo.c
-rHEAD-1".
Anyway, I concede that there is definitely missing functionality here, and I
don't think this has been mentioned before in this discussion so thank you for
bringing this point to light.
> (b) I could create a script to do the necessary SVN LOG scan, pluck out
> the rev#, and paste it into a DIFF/MERGE command. This could work for
> FIXED, but not PREFIXED.
Actually it does work for PREFIXED, by subtracting 1 from FIXED.
> And it depends upon well-formatted log file
> messages, and "prayer-based parsing" common to semi-formal data sets.
Yes. Similarly the script could get the information from a dedicated "bug
number" revision property (look up "revision properties" in the Subversion book
if this doesn't make sense), or from your bug tracker. Either of those could
give you the information in a more formal structure.
> (c) Use mnemonic labels for revisions, and a convention that creates a
> label named "DEFECT-FIX:nnnn" for appropriate check-ins.
Right! Now, why don't your arguments above about tags apply equally to this?
You said:
"But creating a tag for *every* defect fix seems excessive, even if tags are
cheap. And who will remember to do this?"
I say: Creating a tag or a label for every defect only seems excessive if you
think the creation is an expensive operation or if the list of them is going to
make it hard to find other kinds of tags/labels. Creation (of a tag) is not
expensive, and to keep from cluttering your list of release tags (say), you can
use a separate tag name space - e.g. "$TAGS/bugs/..." (This begs the question
of whether the "labels" mechanism would want such a namespace mechanism.)
As for remembering to do it, well, what's there's no difference between
remembering to create a tag and remembering to create a label. Presumably you
would automate it.
> Now FIXED is
> *directly* accessible to me *and* the toolchain.
It appears to me that it would be accessible to the "svn" command via the "-r"
option argument rather than via a normal non-option argument. Is that all you
mean by "directly"?
Perhaps I'm being unreasonably hard on you. I can see that there is some
fairly profound respect in which identifying a marked point in history by path
(a tag) is different from identifying it by revision (a label) ... I just don't
know what the implications of this difference are.
> This leaves PREFIXED up
> in the air, however.
Addressed above.
> So, my ideal is the command:
>
> svn diff foo.c --revision PRIOR:!DEFECT-FIX:1234
>
> Or something like it. Here I'm using "!" to indicate a rev# expressed as
> a label (insert your own syntax here), and am assuming PRIOR means "the
> last time this item was changed" (like COMMITTED but relative to the
> other rev#).
OK. The tags version of that command would be something like:
svn diff $TAGS/DEFECT-FIX-1234/foo.c --revision HEAD-1:HEAD
(The syntax "HEAD-1" or "PRIOR" is not supported yet, but that seems to be
equally necessary for either approach.)
> Skipping the ugly syntax and some significant issues around
> the semantics/implementation of PRIOR, I think this is a significant
> improvement over manually scanning logs.
It seems to me that the syntax and the ability to specify one revision relative
to another are perhaps some of the most important issues here. However, you
are certainly bringing out some interesting points and helping us to understand
the issue. Thanks for your continuing patience in working through this.
- Julian
>> Julian Foad wrote:
>>> Tim Hill wrote:
>>>> Yes, this is certainly one way. The main objection I have to the
>>>> current scheme is that tags are just a convention, and as a result
>>>> the toolchain cannot use the implied REV# information directly -- it
>>>> has to be manually imputed by a user and translated by him/her to a
>>>> REV# for consumption by the toolchain. This makes
>>>> scripting/automation difficult for some common SVN operations and
>>>> adds burden to the dev process.
>>>
>>> Please give an example (stating the desired task and showing actual
>>> commands for doing it) of a situation in which the user has to do
>>> this "translation".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Brad Appleton <br...@gmail.com>.
Tim Hill wrote:
> ok, let's consider patch propogation. I have a mainline build ("main"
> branch) and a release branch ("rel1") that just takes bug fixes for a
> released version of the product. The mainline undergoes cycles of
> dev/test/stabilize, and at each stabilization point a "stable" tag is
> created so that the last stable build is easily accessible.
>
> A bug is found in the mainline in "foo.c". It is tracked in a defect
> tool, fixed in the mainline, checked-in, and undergoes the normal
> dev/test/stabilize process. Product support then decides that the bug is
> serious enough that it should be fixed in the "rel1" branch also, ready
> for the 1.1 release.
>
> How do I merge the fix into the "rel1" branch? Specifically, which
> revisions off the mainline do I compare to get the changes necessary to
> push into "foo.c" in the "rel1" branch?
Thanks Tim for introducing this real-world scenario!
Thinking totally outside of any specific implementation, my first
inclination is to think of a change-set or change-package that
identifies ONLY the set of files that were created/updated to make the
fix and the set of changes/revisions for each file. Those are the set of
files and file versions I want to merge to rel1.
So if a bugfix name/number can be associated with the revision that was
created when I committed the fix to the mainline (and assuming I didnt
do any intermediate "commits" while fixing the bug - which is a BIG
assumption) then I want to apply that revno to only those files that
were changed/added/removed for the bugfix.
This means a revision-alias by itself may be insufficient. The
corresponding revnum tells me the configuration of the codebase at the
time of the commit. It does not give me any easy way to distinguish the
CONTENT of the change/fix from its CONTEXT:
* The CONTENT of the change is the set of changes made to the set of
files+directories that were changed
* The CONTEXT of the change is everything that was NOT changed that was
used to build+test prior to committing my changes.
So, regardless of whether I used a "copy" or a revision-alias, I would
have to do some extra work to identify the CONTENT of the change: either
by limiting the "copy" to be only the set of files changed, or by having
a separate mechanism to know the set of files changed and then
associating it with either a copy or a revision-alias.
In general it seems it would be useful to have some auto/builtin
*qualifier* as a shorthand that could automatically compute this.
I think it would be useful to be able to say something like
REVNO[QUALIFIER], as in HEAD[changed] or HEAD[!changed] or HEAD[wildcard]
I dont particularly like the syntax in my example, but hopefully you get
the idea. And it something that might apply to both revnums and to
"copies" (tho maybe not completely for the latter).
Seems to me that regardless of whether revision-aliases are implemented,
that the ability extract content|context from an associated revno is
still pretty important.
How do I do this today in SVN? Is there a builtin, or do I have to
conjure it up on my own using various conventions and assumptions? (and
properties|comments?)
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
ok, let's consider patch propogation. I have a mainline build ("main"
branch) and a release branch ("rel1") that just takes bug fixes for a
released version of the product. The mainline undergoes cycles of
dev/test/stabilize, and at each stabilization point a "stable" tag is
created so that the last stable build is easily accessible.
A bug is found in the mainline in "foo.c". It is tracked in a defect
tool, fixed in the mainline, checked-in, and undergoes the normal
dev/test/stabilize process. Product support then decides that the bug is
serious enough that it should be fixed in the "rel1" branch also, ready
for the 1.1 release.
How do I merge the fix into the "rel1" branch? Specifically, which
revisions off the mainline do I compare to get the changes necessary to
push into "foo.c" in the "rel1" branch?
There are actually four points in time that are significant (working
backwards):
[1] The rev# of the latest stable build of the mainline branch. Call
this rev# STABLE.
[2] The rev# where the fix to "foo.c" was checked into the mainline
(that is, when the defect was marked as fixed). Call this rev# FIXED.
[3] The rev# where the last change to "foo.c" was made prior to FIXED.
Call this rev# PREFIXED.
[4] The rev# where "rel1" was branched off of the mainline. Call this
rev# REL1.
What I want to merge into the head of "rel1" is: DIFF foo.c -r
PREFIXED:FIXED. However I also need to examine DIFF foo.c -r
REL1:PREFIXED to make sure that the fix does not depend upon changes
made to foo.c between REL1 and PREFIXED. Note that I cannot take DIFF -r
PREFIXED:STABLE since other changes may have occurred in foo.c between
FIXED and STABLE (I'm assuming "rel1" has its own testing/stabilization
cycle).
How do I locate and use the various rev# values needed? STABLE is
available in the "stable" tag noted above, so that's easy (but not much
use in this scenario).
Neither FIXED not PREFIXED are available via tagging. Assuming I'm using
the recommended best practice of marking defect #s in the message log, I
will need to manually examine the log to extract the rev# from the log
messages.
REL1 is available via the --stop-on-copy switch, but this is not
available in the DIFF or MERGE commands, only LOG. So , again, I have to
do a manual scan of the log to obtain the rev#.
This is a lot of work for what is not an unusual scenario. How can it
made less manual (read: less error-prone)?
(a) I could add lots of tags. If FIXED was available as a tag, that
would work. But creating a tag for *every* defect fix seems excessive,
even if tags are cheap. And who will remember to do this? More
importantly, how do I locate PREFIXED? This is a *relative* rev# and is
conceptually related to the COMMITTED rev#, but with an arbitrary
starting point.
(b) I could create a script to do the necessary SVN LOG scan, pluck out
the rev#, and paste it into a DIFF/MERGE command. This could work for
FIXED, but not PREFIXED. And it depends upon well-formatted log file
messages, and "prayer-based parsing" common to semi-formal data sets.
(c) Use mnemonic labels for revisions, and a convention that creates a
label named "DEFECT-FIX:nnnn" for appropriate check-ins. Now FIXED is
*directly* accessible to me *and* the toolchain. This leaves PREFIXED up
in the air, however.
So, my ideal is the command:
svn diff foo.c --revision PRIOR:!DEFECT-FIX:1234
Or something like it. Here I'm using "!" to indicate a rev# expressed as
a label (insert your own syntax here), and am assuming PRIOR means "the
last time this item was changed" (like COMMITTED but relative to the
other rev#). Skipping the ugly syntax and some significant issues around
the semantics/implementation of PRIOR, I think this is a significant
improvement over manually scanning logs.
--Tim
Julian Foad wrote:
> Julian Foad wrote:
>
>> Tim Hill wrote:
>>
>>> Yes, this is certainly one way. The main objection I have to the
>>> current scheme is that tags are just a convention, and as a result
>>> the toolchain cannot use the implied REV# information directly -- it
>>> has to be manually imputed by a user and translated by him/her to a
>>> REV# for consumption by the toolchain. This makes
>>> scripting/automation difficult for some common SVN operations and
>>> adds burden to the dev process.
>>
>>
>> Please give an example (stating the desired task and showing actual
>> commands for doing it) of a situation in which the user has to do
>> this "translation".
>
>
> What I'm getting at is that a tag is not _just_ an alias for a
> revision number, and you shouldn't have to convert it to a revision
> number in order to use it in common situations. You should be able to
> specify it directly in the command - not within the "--revision"
> parameter, because it isn't just a revision, but somewhere in the
> command.
>
> For my example of where you don't have to manually convert it to a
> revision number, I'll find the difference between "foo.c" as it was at
> tag TAG1 and now:
>
> svn diff --old=$TAGS/TAG1 --new=. foo.c
>
> I'll admit again that this syntax is not quite as brief as you might
> want, but it's not grossly inappropriate either, is it? Also, I'll
> admit again that using an environment variable like that is flakey and
> not really acceptable in more complex situations, but that's
> irrelevant to the argument that the user needs to translate the tag to
> a revision number manually.
>
> - Julian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> Tim Hill wrote:
>> Yes, this is certainly one way. The main objection I have to the
>> current scheme is that tags are just a convention, and as a result the
>> toolchain cannot use the implied REV# information directly -- it has
>> to be manually imputed by a user and translated by him/her to a REV#
>> for consumption by the toolchain. This makes scripting/automation
>> difficult for some common SVN operations and adds burden to the dev
>> process.
>
> Please give an example (stating the desired task and showing actual
> commands for doing it) of a situation in which the user has to do this
> "translation".
What I'm getting at is that a tag is not _just_ an alias for a revision number,
and you shouldn't have to convert it to a revision number in order to use it in
common situations. You should be able to specify it directly in the command -
not within the "--revision" parameter, because it isn't just a revision, but
somewhere in the command.
For my example of where you don't have to manually convert it to a revision
number, I'll find the difference between "foo.c" as it was at tag TAG1 and now:
svn diff --old=$TAGS/TAG1 --new=. foo.c
I'll admit again that this syntax is not quite as brief as you might want, but
it's not grossly inappropriate either, is it? Also, I'll admit again that
using an environment variable like that is flakey and not really acceptable in
more complex situations, but that's irrelevant to the argument that the user
needs to translate the tag to a revision number manually.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Tim Hill wrote:
> Yes, this is certainly one way. The main objection I have to the current
> scheme is that tags are just a convention, and as a result the toolchain
> cannot use the implied REV# information directly -- it has to be
> manually imputed by a user and translated by him/her to a REV# for
> consumption by the toolchain. This makes scripting/automation difficult
> for some common SVN operations and adds burden to the dev process.
Please give an example (stating the desired task and showing actual commands
for doing it) of a situation in which the user has to do this "translation".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
Greg Hudson wrote:
>[Tim forgot to cc his reply to the list; I've quoted his full message at
>the end.]
>
>On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
>
>
>>ok, what I'm really looking for is a more convenient way to express
>>the REV# part of the (URL,REV#) co-ordinate space in a repo.
>>
>>
>
>I think that's too specific. What you're really looking for is a more
>convenient way to refer to previously identified versions of specific
>files or directories.
>
>
But isn't that what an (URL,REV#) is?
>Here are my incomplete thoughts on that issue:
>
> * It would be nice if we could make this easier for branches as well
>as tags. Revision aliases might be a perfectly adequate solution for
>tags, but we'd still have exactly the same set of complaints for
>branches, as well as for tags made from branches.
>
> * If we restrict "previously identified versions" to mean branches and
>tags as they are currently conceived of (and not just revision aliases
>as being proposed), then the problem divides into two parts:
>
> 1. Creating a transform scheme by which we can get from,
>say, /trunk/subversion/libsvn_subr/foo.c (specified as just "foo.c" in a
>working directory) to /branches/blah/subversion/libsvn_subr/foo.c,
>without hardcoding layouts of the repository namespace. One option
>would be to use directory properties to identify where the branches and
>tags are.
>
> 2. Creating a syntax to use this transformation scheme. One option
>would be to invent a kind of revision specifier which transforms a URL;
>another would be to invent a kind of URL syntax which uses the transform
>rule; another would be to invent a new option type alongside -r.
>
>
Yes, this is certainly one way. The main objection I have to the current
scheme is that tags are just a convention, and as a result the toolchain
cannot use the implied REV# information directly -- it has to be
manually imputed by a user and translated by him/her to a REV# for
consumption by the toolchain. This makes scripting/automation difficult
for some common SVN operations and adds burden to the dev process.
>I'll throw out a sketch of a straw-man proposal within the above
>solution space: (1) we introduce a directory property "svn:transforms"
>whose value is a series of lines which look like "T /trunk /tags". Each
>line defines a named transformation rule; in the example, the rule name
>is "T" and the rule substitutes the FS path prefix /trunk with /tags and
>adds in the tag name as a path component; (2) we introduce a revision
>specifier syntax "rule#path[@rev]" which transforms the URL according to
>the svn:transforms value in the current directory, and uses either the
>specified revision or the head revision. So you would do "svn diff -r
>T#mytag foo.c" to diff a file against a tag, with the example transform
>rule.
>
>On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
>
>
>>ok, what I'm really looking for is a more convenient way to express
>>the REV# part of the (URL,REV#) co-ordinate space in a repo. The
>>trouble with tags is that the toolchain doesnt understand that a tag
>>is really a REV# in disguise, as it were, and so its up to humans to
>>track that and translate back to a real rev# when entering many SVN
>>commands. This, to me, seems a significant deficiency in tags.
>>
>>So, is there some way this can be handled within the tag paradigm? It
>>seems to me that a tag branch does imply a REV# (actually, a whole set
>>of REV#s). What we really want is a way for the toolchain to accept
>>these values as direct input to the --revision switch. That would
>>imply that the --revision switch could accept an URL as an argument,
>>though I've not thought through what this would actually mean
>>semantically (yet).
>>
>>--Tim
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
>
Re: Subversion "labels" vs. "tags"
Posted by Greg Hudson <gh...@MIT.EDU>.
[Tim forgot to cc his reply to the list; I've quoted his full message at
the end.]
On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
> ok, what I'm really looking for is a more convenient way to express
> the REV# part of the (URL,REV#) co-ordinate space in a repo.
I think that's too specific. What you're really looking for is a more
convenient way to refer to previously identified versions of specific
files or directories.
Here are my incomplete thoughts on that issue:
* It would be nice if we could make this easier for branches as well
as tags. Revision aliases might be a perfectly adequate solution for
tags, but we'd still have exactly the same set of complaints for
branches, as well as for tags made from branches.
* If we restrict "previously identified versions" to mean branches and
tags as they are currently conceived of (and not just revision aliases
as being proposed), then the problem divides into two parts:
1. Creating a transform scheme by which we can get from,
say, /trunk/subversion/libsvn_subr/foo.c (specified as just "foo.c" in a
working directory) to /branches/blah/subversion/libsvn_subr/foo.c,
without hardcoding layouts of the repository namespace. One option
would be to use directory properties to identify where the branches and
tags are.
2. Creating a syntax to use this transformation scheme. One option
would be to invent a kind of revision specifier which transforms a URL;
another would be to invent a kind of URL syntax which uses the transform
rule; another would be to invent a new option type alongside -r.
I'll throw out a sketch of a straw-man proposal within the above
solution space: (1) we introduce a directory property "svn:transforms"
whose value is a series of lines which look like "T /trunk /tags". Each
line defines a named transformation rule; in the example, the rule name
is "T" and the rule substitutes the FS path prefix /trunk with /tags and
adds in the tag name as a path component; (2) we introduce a revision
specifier syntax "rule#path[@rev]" which transforms the URL according to
the svn:transforms value in the current directory, and uses either the
specified revision or the head revision. So you would do "svn diff -r
T#mytag foo.c" to diff a file against a tag, with the example transform
rule.
On Sun, 2005-05-29 at 23:26 -0700, Tim Hill wrote:
> ok, what I'm really looking for is a more convenient way to express
> the REV# part of the (URL,REV#) co-ordinate space in a repo. The
> trouble with tags is that the toolchain doesnt understand that a tag
> is really a REV# in disguise, as it were, and so its up to humans to
> track that and translate back to a real rev# when entering many SVN
> commands. This, to me, seems a significant deficiency in tags.
>
> So, is there some way this can be handled within the tag paradigm? It
> seems to me that a tag branch does imply a REV# (actually, a whole set
> of REV#s). What we really want is a way for the toolchain to accept
> these values as direct input to the --revision switch. That would
> imply that the --revision switch could accept an URL as an argument,
> though I've not thought through what this would actually mean
> semantically (yet).
>
> --Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2005-05-28 at 17:52 -0700, Tim Hill wrote:
> 1. I don't really buy the "you can do it with tags, so who needs labels"
> argument.
The argument (at least, the one I made) is not that tags are good
enough, but that we want to be wary of having two substantially
different mechanisms for doing very similar things. Under the
revision-aliases proposal, if you want to mark a particular rev of a
tree, you can either use revision aliases ("labels") to get access via
-r, or you can use tags to get browsability through ra_dav, a historical
record of the operation in the same form as a commit (*), and
identification of the part of the tree the tag applies to. If you want
a combination of these advantages, you might be tempted to make *both* a
revision alias and a tag.
Yes, it's inconvenient to use tags for some use cases, and those use
cases would be simpler if we had revision aliases or some other
conception of labels. But I would be happier if we could come up with
an answer which didn't give us two radically different mechanisms, each
with a distinct subset of the operational properties people want from a
tagging-type operation.
(*) The more simplistic revision-alias proposals involve creating an
unversioned table of revision aliases, which would be similar in concept
to CVS's tags. I would be rather down on this approach. Branko's
proposal which uses revision properties could be made to have history if
we add revision property history (which we could do pretty easily), but
the historical record of a revision alias would still be in a very
different form than the repository's usual historical records, and that
could be rather inconvenient.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
OK, and my apologies if I came over a little aggressive in my post --
was starting to feel I was fighting uphill :( Here's the best I can do
to describe my thought processes (a re-hash of another post)...
In an SVN repo, any item has a unique co-ord comprising an (URL,REV#)
pair (let's ignore renames etc for now). Now, URLs are more-or-less
mnemonic names (good for humans), and both the OS and SVN provide many
tools to browse/list/locate an URL in a large tree. The problem as I see
it is that the REV# part of the co-ord pair is the "poor man" in this
equation. The user must either remember an integer or a date (and the
date can be ambiguous in some cases). Users are *not* good at this, so
it is good if a way can be found to enhance the REV# part with more
mnemonic values or provide other automatic means to assist in the use of
REV# values.
Tags are one way to do this. At root, a tag is a translation from the
REV# "dimension" of the repo to the URL dimension, and hence translates
the "hard" REV# into an "easy" (to recall/search) URL. BUT the mechanism
in SVN used to provide tags (actually just a cunning re-use of
branching) in a technical sense loses information -- specifically the
*formal* knowledge that the tag is indeed an alias for a REV#. This
information loss has two consequences: (a) users are not aware that the
tag is, indeed, a tag (without naming conventions, which are fragile)
and (b) the toolchain cannot *automatically* translate back from a tag
URL to a REV#.
What are the results of this?
1. Tags need extra vigilance by admins, either manually or with
semi-hacked scripts, to enforce the "tag-ness" of tag branches. Users
need to be educated out-of-band (there is no toolchain help) about what
tags are and how they must be used. Since the toolchain has no knowledge
of tag semantics, it cannot help (directly) enforce any of these
conventions.
2. Translation of a tag URL back to a REV# is a manual process,
involving locating the tag, discovering the REV#, and then manually
transcribing that REV# into appropriate SVN commands. This is
error-prone, cumbersome, and not conducive to automation/scripting.
Therefore, what I am lobbying for is a mnemonic way to describe REV#
values that does not lose semantic information, iow some form of
mnemonic tag that the toolchain *does* understand as representing a REV#
and can therefore (a) enforce semantically and (b) consume directly. One
implementation might be some form of alphanumeric value that can be
associated with a REV# and accepted directly by the toolchain as an
argument to the --revision switch, but other implementations are of
course possible.
A non-goal, to my mind, is to replace the current tag mechanism totally.
My expectation would be that "labels" would be a lightweight system that
was adequate for linear development and intermediate (non-milestone)
revisions, but tags would almost certainly continue as the primary way
to mark milestones and/or track more complex non-linear deve processes.
Now, I'm *very* aware that even a simple label system has many issues
that need to be resolved (scope, namespace etc), and I'm more that happy
to assist in this analysis on the way to a design that meets real user
requirements and is cost-effective to implement (and is backward
compatible, of course).
--Tim
Julian Foad wrote:
> Tim Hill wrote:
>
>> Sorry, I have to disagree with these arguments, Julian.
>
>
> I may well be wrong and I'm glad to have your input. However, I
> wasn't really making any arguments in that post.
>
> I think you have somewhat misunderstood my position. In this thread I
> am trying to get people to explain what is wrong and what would
> exactly would be better. I'm not claiming that I know the answers at
> all. I am seeing vague requests for improvement, but not yet
> proposals with enough detail.
>
>
>> I agree with David that labels are a useful, and even necessary
>> addition to SVN.
>
>
> [p.s. After writing the many following paragraphs I reached the end of
> your mail where you say what kind of labels you want. Having written
> so much, I don't want to delete it, but I wouldn't have written much
> of this if I'd read your message to the end first. So apologies for
> the frustrated tone of this...]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
Tim Hill wrote:
> Sorry, I have to disagree with these arguments, Julian.
I may well be wrong and I'm glad to have your input. However, I wasn't really
making any arguments in that post.
I think you have somewhat misunderstood my position. In this thread I am
trying to get people to explain what is wrong and what would exactly would be
better. I'm not claiming that I know the answers at all. I am seeing vague
requests for improvement, but not yet proposals with enough detail.
> I agree with
> David that labels are a useful, and even necessary addition to SVN.
[p.s. After writing the many following paragraphs I reached the end of your
mail where you say what kind of labels you want. Having written so much, I
don't want to delete it, but I wouldn't have written much of this if I'd read
your message to the end first. So apologies for the frustrated tone of this...]
I wish that you would acknowledge that there is not yet an established specific
meaning of the term "label" in the Subversion community. Half of this
discussion so far has been about whether people want to label global revision
numbers or collections of arbitrary versions of arbitrary files or what. It's
no good asserting that "labels are useful" without saying what the labels are
labelling.
For instance, you may be accustomed to some particular version control system
in which the term "label" has some specific meaning which by now is so
intuitive to you that you forget that to me it just means "a word that refers
to a thing".
> 1. I don't really buy the "you can do it with tags, so who needs labels"
> argument. Frankly, following this reductionist argument, you can do
> everything SVN does with a well-designed directory layout/scheme, a DIFF
> command, and a book detailing all the necessary conventions to follow.
> So why does everyone use SCC systems? Because the *computer* should do
> the book-keeping and grunt work, not the dev, since (a) it's what they
> are good at and (b) it's what devs are bad at. However, the current tag
> model is a convention enforced and manged by the dev/admin and not the
> tool. Huh?
OK, I completely agree with what you here, that the tool should do whatever
book-keeping grunt-work is useful. Can you/we please try to define what this
required behaviour is that you refer to as "it" in "you can do it with tags"?
If I seemed to be saying that the current implementation of tags is good enough
for what you or most people want, I apologise. But in order to design a
feature that will make you happy, that we are tentatively calling "labels", we
need to specify exactly what behaviour is required from this feature. We don't
seem to be getting very far with this specification.
A good way of moving forward would be for somebody to write a first draft of a
specification for the _requirements_ (not implementation method) of the
feature, and then we can comment on it and revise it until most people agree
that it is good and feasible. The form of this proposal would be something like:
[[[
PROPOSAL FOR LABELLING INTERESTING VERSIONS OF A PROJECT
Subversion's concept of "tags" is too flexible to provide the desired level
of support to a repository administrator in the following common situations:
[...] where the following drawbacks are apparent: [...] This proposal is for a
scheme which [adds to / replaces / modifies] Subversion's concept of "tags" to
solve most of those problems.
The basis of this scheme is that users should be able to label certain
restricted groups of repository data. The label itself will be a [versioned /
unversioned] resource: in other words its lifetime shall be [...]. When there
is more than one project in a repository, the labels shall [...]. Labels can
apply to branches as well as to the trunk, in the following way: [...]
A label refers to [...]. It is created by [...] and [can / cannot] be
destroyed, renamed, or moved to refer to different data, in these ways: [...]
[...]
The term "label" will now have the specific meaning defined above when used
in the context of Subversion.
]]]
> 2. Following the "simple scenarios should have simple solutions" model,
> how do I simply track a linear development process so that I can easily
> refer back to an earlier rev for a quick diff? Without labels, I have
> three choices (a) manually track dates/ rev numbers in some external
> dataset (e.g. a spreadsheet), (b) over-load the message field with yet
> another semi-formal data item or (c) use tags.
>
> Now, (a) would seem to indicate a lack of something in the toolchain.
> (b) is horrible since the message field is already badly overloaded (bug
> tracking, branch merge tracking etc.). So we're left with (c), but this
> is *not* a _simple_ solution to the simple problem -- far from it.
You may be right, but it is far from obvious that (c) is not a simple solution.
Did you see the examples of how to create a tag and diff against a tag
earlier in this thread? One of the most obvious problems was that the whole
URL to the repository had to be specified on the command line, but that was
shown to be worked around quite simply and neatly in the simple cases by
defining an environment variable containing the URL of the repository's tags.
I'm not saying that's an ideal solution, just that if that is one of the main
problems then it would indicate that we probably don't need to re-design the
whole concept of tags. We may be able to make the situation 90% better via a
couple of relatively minor enhancements, and that would be a good thing for
everybody even if that still leaves the remaining 10% of usability under
discussion for a longer-term feature enhancement.
Please explain how specific aspect of the existing usage are not simple enough,
or not good enough, so that we can understand why a new design is needed. Give
examples of every-day use cases, and we'll see where the existing usage is not
good enough and we'll assess the best way to improve the user experience. Of
course the developers are biased towards keeping things as they are, but I
don't believe they (we) are strongly biased; they/we are quite willing to
accept that a change is needed if shown some convincing real examples.
> 3. Tags, as second-class objects, are not understood by the toolchain.
Right. That does feel wrong to me, but I haven't yet seen a clear
demonstration that it is actually wrong or bad or unhelpful. For instance, I
haven't yet seen how the difference between the two potential syntaxes:
svn diff -rTAG1:TAG2 foo.c
and
svn diff --old=$TAG1 --new=$TAG2 foo.c
is any more than "syntactic sugar", i.e. something that could be "fixed" by a
simple change to the command-line interpreter. (On the other hand, I do feel
that there is a fundamental difference between the concepts implied by those
two syntaxes, in that the former implies that tags are (approximately)
unversioned aliases for revision numbers, while the latter doesn't.)
> What is the SVN command to compare two revisions of a file if I don't
> remember the rev # of the earlier file? I have to wander around in the
> tags directory, then manually construct a suitable svn command. Urgh!
Huh? You are not describing your concern very well. In what way do you think
you wouldn't have to "wander around" in the list of tags (or "labels") to find
the one you want if they were a first-class object? And in what sense do you
think you wouldn't have to "manually construct a suitable svn command"?
> IMHO there are already too many places where the svn "best practice" is
> "scan the log messages for magic comments, note the rev #, type it into
> a subsequent command" -- yet again, we are back into the devs doing
> book-keeping for the computer!
OK, I agree with this concern - but what is your proposal for improving the
situation? (Sorry to keep asking - I am really not trying to annoy you.)
> 4. Pragmatically, I have already seen too many shops using a "roll your
> own" label scheme to believe that labels are unnecessary. Some shops use
> external files and a nightmare of hacked scripts to inject revision
> numbers into svn commands. Others hack them into properties and then
> (again) hack together scripts to automate as much as possible. All of
> these shops are working around what they see as a weakness in svn --
> what they are *not* using, however, is tags.
OK. Could you or anyone present one or more of these cases here, to show what
is required?
> So, why argue for labels?
(Well, I still don't know what these labels are that you are arguing for.)
> My feeling is that an SVN repo is in fact a
> two dimensional store -- one dimension being the directory tree, the
> other being the revision number. A node in this space is located by the
> combination of (URL,REV#).
Good - that's exactly how the docs and the designers see it.
> Access to the URL co-ordinate is relatively
> easy because (a) users remember mnemonic names quite well and (b) both
> the OS and SVN provide many browse/search assists for this space. Access
> to the REV# co-ordinate is *not* as easy since (a) users do NOT remember
> numbers easily and (b) SVN provides few tools (and the OS none) to help
> locate rev numbers.
OK.
> Tags try to overcome this by essentially translating the REV#
> co-ordinate _into_ an URL co-ordinate. Labels try to overcome this by
> providing direct mnemonic aliases for the REV# co-ordinates. We already
> have the tags solution, so why do we need labels? Because once a REV# is
> translated to an URL via a tag, it *loses* information in the form of
> its type -- the toolchain no longer understands that the tag is a REV#
> and hence cannot usefully enforce or use that information. So there is
> *no* direct way to specify the REV# _implied_ by a tag in an SVN command
> -- hence all the awkward syntax and cumbersome use of URLs in many
> otherwise simple SVN scenarios.
OK, thank you. So you want your "label" to be a reference to a revision
number. That's fine. That's the type of label which C-Mike Pilato outlined
right at the binning of this thread (but got no response) and for which Brane
has a concrete low-level implementation proposal.
Great. I can see that this type will be useful, without much in the way of
examples. We still need to work out the details, like how they work when there
is more than one project in the repository, what their scope is tree-wise, what
their lifetime is, whether they are unversioned or versioned, etc. So we still
need to discuss some use cases.
>
> Put another way, an ordinary, plain old developer needs a simple way to
> say "diff the current rev of foo.c against a known reference" that (a)
> doesn't involve memorizing rev# and (b) doesn't require mastering branches.
Yay! OK, let's go ahead with implementing this type of label, i.e. references
to revision numbers.
HOWEVER, bear in mind that this did not seem to be the type of label that
everybody wanted. Some other people want some enhancement to the tags concept.
So, let the design discussions proceed in two separate threads: "Labelling
revision numbers" (being what you are talking about) and "Enhancements to tagging".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Tim Hill <ti...@realmsys.com>.
Sorry, I have to disagree with these arguments, Julian. I agree with
David that labels are a useful, and even necessary addition to SVN.
1. I don't really buy the "you can do it with tags, so who needs labels"
argument. Frankly, following this reductionist argument, you can do
everything SVN does with a well-designed directory layout/scheme, a DIFF
command, and a book detailing all the necessary conventions to follow.
So why does everyone use SCC systems? Because the *computer* should do
the book-keeping and grunt work, not the dev, since (a) it's what they
are good at and (b) it's what devs are bad at. However, the current tag
model is a convention enforced and manged by the dev/admin and not the
tool. Huh?
2. Following the "simple scenarios should have simple solutions" model,
how do I simply track a linear development process so that I can easily
refer back to an earlier rev for a quick diff? Without labels, I have
three choices (a) manually track dates/ rev numbers in some external
dataset (e.g. a spreadsheet), (b) over-load the message field with yet
another semi-formal data item or (c) use tags.
Now, (a) would seem to indicate a lack of something in the toolchain.
(b) is horrible since the message field is already badly overloaded (bug
tracking, branch merge tracking etc.). So we're left with (c), but this
is *not* a _simple_ solution to the simple problem -- far from it.
3. Tags, as second-class objects, are not understood by the toolchain.
What is the SVN command to compare two revisions of a file if I don't
remember the rev # of the earlier file? I have to wander around in the
tags directory, then manually construct a suitable svn command. Urgh!
IMHO there are already too many places where the svn "best practice" is
"scan the log messages for magic comments, note the rev #, type it into
a subsequent command" -- yet again, we are back into the devs doing
book-keeping for the computer!
4. Pragmatically, I have already seen too many shops using a "roll your
own" label scheme to believe that labels are unnecessary. Some shops use
external files and a nightmare of hacked scripts to inject revision
numbers into svn commands. Others hack them into properties and then
(again) hack together scripts to automate as much as possible. All of
these shops are working around what they see as a weakness in svn --
what they are *not* using, however, is tags.
So, why argue for labels? My feeling is that an SVN repo is in fact a
two dimensional store -- one dimension being the directory tree, the
other being the revision number. A node in this space is located by the
combination of (URL,REV#). Access to the URL co-ordinate is relatively
easy because (a) users remember mnemonic names quite well and (b) both
the OS and SVN provide many browse/search assists for this space. Access
to the REV# co-ordinate is *not* as easy since (a) users do NOT remember
numbers easily and (b) SVN provides few tools (and the OS none) to help
locate rev numbers.
Tags try to overcome this by essentially translating the REV#
co-ordinate _into_ an URL co-ordinate. Labels try to overcome this by
providing direct mnemonic aliases for the REV# co-ordinates. We already
have the tags solution, so why do we need labels? Because once a REV# is
translated to an URL via a tag, it *loses* information in the form of
its type -- the toolchain no longer understands that the tag is a REV#
and hence cannot usefully enforce or use that information. So there is
*no* direct way to specify the REV# _implied_ by a tag in an SVN command
-- hence all the awkward syntax and cumbersome use of URLs in many
otherwise simple SVN scenarios.
Put another way, an ordinary, plain old developer needs a simple way to
say "diff the current rev of foo.c against a known reference" that (a)
doesn't involve memorizing rev# and (b) doesn't require mastering branches.
--Tim
Julian Foad wrote:
> David Weintraub wrote:
> [...]
>
>> Is there another way to use "switch"? Can I simply "switch" just a few
>> files and not my whole working directory?
>
>
> Yes, and yes. You just specify the files and/or directories that you
> want to switch as arguments to the command.
>
>
> OK, so you don't want a "label" to just mark a point in time, you want
> it to mark a set of particular versions of particular files. So the
> concept is the same as Subversion's "tags"; it's just the useability
> that bothers you.
>
>
> If you will now agree that the concept that you call a "label" is the
> same as the concept that Subversion developers call a "tag", then we
> seem to have arrived at a shared view. (The need to set up hook
> scripts and use awkward syntax in order to use tags in Subversion is
> part of the implementation and user interface, not the concept.)
>
> Now we need to see in what respects the use is _too_ awkward at
> present, and in what respects it is just a little awkward but could be
> made better anyway, and then we could see about improving it.
>
> - Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Pedro Lamarão <pe...@intersix.com.br>.
Julian Foad wrote:
[SNIP]
> If you will now agree that the concept that you call a "label" is the
> same as the concept that Subversion developers call a "tag", then we
> seem to have arrived at a shared view. (The need to set up hook scripts
> and use awkward syntax in order to use tags in Subversion is part of the
> implementation and user interface, not the concept.)
>
> Now we need to see in what respects the use is _too_ awkward at present,
> and in what respects it is just a little awkward but could be made
> better anyway, and then we could see about improving it.
A quick search in the Subversion home-page couldn't find a document
describing the reasoning in this thread.
It seems that the developer's understanding on this "label" dilemma
could use greater exposition.
Wouldn't it be a good idea to have a Rationale document, maybe even an
answer in the FAQ, about this?
--
Pedro Lamarão
Desenvolvimento
Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br
Your Security is our Business
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
David Weintraub wrote:
[...]
> Is there another way to use "switch"? Can I simply "switch" just a few
> files and not my whole working directory?
Yes, and yes. You just specify the files and/or directories that you want to
switch as arguments to the command.
> Making labels synonyms for revision numbers would probably accomplish
> 90% of what is needed for labels (and with the use of tags and hooks,
> we could do the rest). However, in all other version control systems,
> you can choose what to tag. If I have four separate projects in my
> repository, I may only want to label the flies in only one of those
> projects. If labels are synonyms for revision numbers, putting a label
> would mark all of my projects.
OK, so you don't want a "label" to just mark a point in time, you want it to
mark a set of particular versions of particular files. So the concept is the
same as Subversion's "tags"; it's just the useability that bothers you.
> [...] To me, the actual
> implementation is not important. I hated it when I was a developer and
> my managers told me I had to use a particular implementation just
> because they thought it was the latest thing to do.
I have been in that position and felt the same as you. People very often do
that when asking for something - "I need a feature called X" - when really they
only need some behaviour that they could have got from a feature called X. It
is part of our job as designers to ask "What, really, is the behaviour that you
need?"
> However, labels are an important concept in version control and
> configuration management, but they are still awkward to use in
> Subversion.
If you will now agree that the concept that you call a "label" is the same as
the concept that Subversion developers call a "tag", then we seem to have
arrived at a shared view. (The need to set up hook scripts and use awkward
syntax in order to use tags in Subversion is part of the implementation and
user interface, not the concept.)
Now we need to see in what respects the use is _too_ awkward at present, and in
what respects it is just a little awkward but could be made better anyway, and
then we could see about improving it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
On 5/23/05, Julian Foad <ju...@btopenworld.com> wrote:
> David Weintraub wrote:
> > For example, I'd like to use an older version
> > of a particular file in my current working directory. If I knew the
> > version number, I could do this:
> >
> > $ svn update -r<REV> foo.c
> >
> > But, I can't use the "svn update" with a tag at all. Instead, I have
> > to use svn copy:
>
> No, no, no. Use "switch" for that. Have you read the Subversion book? I
> believe it explains how "switch" is the more general form of "update", able to
> change your WC to reflect another place in your project tree (e.g. to a tag) as
> well as another point in time.
Yes, the book explained how "switch" is a superset of the "update"
command, but it uses it as a way to work off a branch. That is, you
switch the whole URL to a branch. This way, you don't have to create a
whole new working directory, and you hope that the changes between
where you were working and the branch you're currently working on are
minor, so the "switch" command is more efficient than a new checkout.
Is there another way to use "switch"? Can I simply "switch" just a few
files and not my whole working directory?
Many times, developers discover bugs in the most recent versions of a
few files that prevents them from doing their work. They'd like to
revert just those files to the last good build and continue their
work. Once the bugs in the problematic files are fixed, they'll update
once again to the latest versions of those files.
> Ah, but maybe you are assuming that tags or labels only refer to a previous
> version of the current line of development of a file - that is, a direct
> ancestor of the current head. If you want a "label" to be strictly a synonym
> for a revision number, that's a much easier problem and one which is pretty
> much separate from (orthogonal to) Subversions's tags. You haven't yet said
> (on this list) what you want a "label" to be.
Labels can be used as snapshots in time, and I use them to mark the
versions of each file in every build. It isn't uncommon for an
environment have a label like "BLESSED" that points to the last
"blessed" copy of the build.
Making labels synonyms for revision numbers would probably accomplish
90% of what is needed for labels (and with the use of tags and hooks,
we could do the rest). However, in all other version control systems,
you can choose what to tag. If I have four separate projects in my
repository, I may only want to label the flies in only one of those
projects. If labels are synonyms for revision numbers, putting a label
would mark all of my projects.
> You've probably gathered by now how most developers feel about the way tagging
> is done:
>
> o The status quo is intentionally very flexible.
> o It works sufficiently well in practice.
> o The command-line user interface is more clumsy than it need be for the
> common use cases. There is room for improvement and we are glad to discuss this.
> o GUIs can provide a much slicker interface.
> o A need for an alternative or additional tagging concept has not been
> sufficiently demonstrated by anyone.
I agree with the first two points: Subversion is very flexible, and
tags as they stand now do work. Unfortunately, I also agree with the
third point to: The command-line user interface can be awkward when
refering back to a tag/label/or whatever you want to call it. .
The goal is to be able to use whatever labels will be in a fairly
simple and straight forward manner as found in other version control
systems. For example, I can do this in RCS:
$ co -r2.1 foo.c
And, that will check out revision 2.1 of file foo.c into my working
directory. I can also do this:
$ co -rREV_1_2 foo.c
And that will checkout the version of foo.c with the label REV_1_2.
And that will checkout all the files with the label REV_1_2 on them.
(The same with the rcsdiff and all other rcs commands)
This could easily be done by making a lookup table between labels and
revision numbers. However, in almost all other version control
systems, I can selectively apply my label to a subset of files if I so
choose. It allows me to mark what files actually were involved in a
release or build and which ones aren't. A simple lookup table in
Subversion would not allow me to do this.
Maybe the solution is to improve the command line interface to make
tags easier to use in this manner. Maybe the solution is to use
properties and have an easy way to select files via properties. Maybe
the solution is to create a lookup table. To me, the actual
implementation is not important. I hated it when I was a developer and
my managers told me I had to use a particular implementation just
because they thought it was the latest thing to do.
However, labels are an important concept in version control and
configuration management, but they are still awkward to use in
Subversion.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Julian Foad <ju...@btopenworld.com>.
David Weintraub wrote:
> For example, I'd like to use an older version
> of a particular file in my current working directory. If I knew the
> version number, I could do this:
>
> $ svn update -r<REV> foo.c
>
> But, I can't use the "svn update" with a tag at all. Instead, I have
> to use svn copy:
No, no, no. Use "switch" for that. Have you read the Subversion book? I
believe it explains how "switch" is the more general form of "update", able to
change your WC to reflect another place in your project tree (e.g. to a tag) as
well as another point in time.
Ah, but maybe you are assuming that tags or labels only refer to a previous
version of the current line of development of a file - that is, a direct
ancestor of the current head. If you want a "label" to be strictly a synonym
for a revision number, that's a much easier problem and one which is pretty
much separate from (orthogonal to) Subversions's tags. You haven't yet said
(on this list) what you want a "label" to be.
> The reason we decided to start the discussion over here was to allow
> the developers their say. How do they feel about adding a particular
> set of features? What is the best way to implement such a feature? Is
> it really worth the time and effort? Does it fit in with the way
> Subversion currently works?
You've probably gathered by now how most developers feel about the way tagging
is done:
o The status quo is intentionally very flexible.
o It works sufficiently well in practice.
o The command-line user interface is more clumsy than it need be for the
common use cases. There is room for improvement and we are glad to discuss this.
o GUIs can provide a much slicker interface.
o A need for an alternative or additional tagging concept has not been
sufficiently demonstrated by anyone.
I am sorry if I haven't yet understood what you are asking for.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
No one is saying there is no way to "label" a file as of now. It's
just unwieldy. When I was using SCCS, we created labels by creating a
text file containing a list of files and their version numbers we
wanted in a release and put those lists in SCCS. We were able to do
"labels" in SCCS, but no one complained when RCS came along and had
labels built right in.
Yes, you can use hooks to prevent tag corruption, but the concept of a
label should be internal to a version control system. Right now,
keeping the tags meaningful depends upon the administrator using hooks
or other means to keep users from destroying them. For example, with
the hooks I have in Subversion, no one can mess with the tags
directory, but no one can create a tag either.
Yes, you can use the diff --old=<URL> --new=<URL> label, but you have
to know exactly what you're looking for and the syntax is a bit
awkward to put it mildly:
$ svn diff --old=http://myweb/myrepos/myproj/tags/REL1.0/dir1/dir2/dir3/foo.c
--new=./foo.c
I guess you can even get around a few of the other commands with the
current implementation. For example, I'd like to use an older version
of a particular file in my current working directory. If I knew the
version number, I could do this:
$ svn update -r<REV> foo.c
But, I can't use the "svn update" with a tag at all. Instead, I have
to use svn copy:
$ rm foo.c
$ svn copy http://myweb/myrepos/myproj/tags/REL1.0/dir1/dir2/dir3/foo.c .
But is the behavior exactly the same? What would an "svn update" do,
or a "svn commit"?
As I said, it's possible to use the tag directory as currently
structured as a label, and I do use it, but it would be nice if there
was an easier way to use labels.
The reason we decided to start the discussion over here was to allow
the developers their say. How do they feel about adding a particular
set of features? What is the best way to implement such a feature? Is
it really worth the time and effort? Does it fit in with the way
Subversion currently works?
I understand not wanting Subversion getting feature bloat (Where are
the cup holders?). But labeling is a rather basic concept in version
control.
One of the options discussed on the user list was extending the
"directory for label" concept a bit more. Have a special "labels"
directory (like you have a "tags" directory), but give Subversion some
basic understanding of the concept of a label:
* Subversion itself would understand that the "label" directory is
special. Maybe specify the "label" directory (or maybe directories?)
in Subversion's repository directory.
* Subversion would understand that a "mklabel" command means doing a
URL copy to this specific directory.
* Subversion would let people "make labels" that is, do a URL copy to
an empty directory, but not allow just anyone to commit any changes
under this directory to pre existing files. Users can create labels,
but not modify them.
* Have Subversion understand that if a label is being specified in a
--revision parameter, you are really specifying the version of the
file that is under the "label" directory.
This way, the command set is being expanded by a single "mklabel"
command which is really just an alias to the copy command. There is no
real new data structure or concepts. There is no new name space
created. Just that Subversion now understands that a particular
directory has special meaning. You can list, edit, modify, and even
delete labels using the current Subversion command set (if you are the
administrator).
It sounds a bit difficult to implement, and there has to be several
items clarified. For example, if I have a repository directory
http://myrepos/myproj/trunk/dir/dir2/bin/, and I decide to make a tag
REL2.0 for bin, I could do any of the following:
$svn cp http://myrepos/myproj/trunk http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir/dir2 http:/myrepos/myproj/tags/REL2.0
$svn cp http://myrepos/myproj/trunk/dir/dir2/bin
http:/myrepos/myproj/tags/REL2.0
All will save my bin directory under REL2.0. However, what does this mean?
$ svn co http://myrepos/myproj/trunk/dir/dir2/bin .
$ svn diff -rREL2.0 foo
Where does REL2.0 of foo exist in the archive? It all depends whether
I copied the whole structure to my REL2.0 directory, or just the bin
directory, or anything in between. How could Subversion know where I
put the file "foo" under the directory tags/REL2.0?
Another simpler method for implementing labels is to create a lookup
table containing labels and revision numbers (and maybe a reverse
lookup table). Now, when I specify:
$svn diff -rREL2.0 foo,
You can go to the lookup table, see what revision "FOO" represents,
and substitute that revision number.
Of course, that means adding a few more structures to the Subversion
archive, a command to make labels, a command to edit labels, a command
to list labels, a command to delete labels, etc. And, you now have
tags vs. labels as two different ways to do similar things. Plus, you
can't specify what exactly got labeled with a particular label. If my
repository contains multiple projects, all projects get that label.
We just thought it was time to get some developer input on the matter.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-05-23 at 13:12 -0400, David Weintraub wrote:
> Let's try this again with the correct subject line...
When you're starting a new thread on a mailing list, it's not
appropriate to reply to an existing message, even if you remember to fix
up the subject line. There is threading information in replies (which
you typically can't see while composing the message, in most mail user
agents) which can cause your new thread to get lost in the display of
other people's mail programs.
(I'm not suggesting you restart the thread; this is just for future
reference. At this point, splitting the thread by restarting it would
do more harm than good.)
As to your suggested feature:
* I am concerned about having two different ways of doing almost the
same thing.
* I am concerned about expanding the command set.
* I am concerned about creating a CVS-style tag namespace which is
non-hierarchical and is orthogonal to the file namespace. In my
experience with CVS, the tag namespace tends to become very cluttered.
* I am concerned that by making labels an alias for revision numbers,
it may not always be clear what part of a repository's file namespace
the label pertains to. There is no such ambiguity with directory
copies.
* I recognize that having to protect the sanctity of tags with a hook
script, and not being able to use tags as revision arguments, are
drawbacks to Subversion relative to CVS. I wonder if there might be
better ways around these problems.
> There is also no way a tag can be used in Subversion's "svn" sub
> commands. For example, in order to compare the current version of
> foo.c with foo.c in revision REV1.2, you have to either...
This is not true; you can "svn diff http://blah/tags/blah/foo.c foo.c".
Obviously, that's pretty unwieldy, but it's not impossible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Weintraub <qa...@gmail.com> writes:
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can
> checkout the tag's directory, make modifications, then commit those
> changes. This means an admin could create a REV1.0 tag directory,
> and have users change it without the administrator's knowledge.
Well, to be clear, it may be changed in a way that doesn't draw the
administrator's attention, but not in a way that can elude an
administrator's ability to determine that change has happened.
> We also discussed several ways labels could be implemented: As a
> special property on files, as an alias to a particular revision
> number, and as a special instance of a "tag". However, we realize the
> question of how labels should be implemented is really up to the
> developers.
I would discourage the use of labels on anything but whole revisions.
I would suggest allowing the setting of multiple labels per revision.
And I would avoid using properties for the storage format -- make the
labels a first-class data object.
- Add a new 'labels' table which maps labels to revisions
- Possibly add a reverse mapping, though only if folks need to ask
"What labels are associate with revision REV?"
- Give the RA layers and repos layer a "label-to-rev" lookup
routine.
Done deal, right?
We could probably even do this in the 1.x line, soft-upgrading
repositories to make the new table, making the new RA layer gracefully
fail when the server doesn't support the new lookup...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion "labels" vs. "tags"
Posted by Max Bowsher <ma...@ukf.net>.
David Weintraub wrote:
> We agree that tags have several short comings:
>
> Tags are not first class objects in Subversion -- just another
> directory. It is up to the administrator to know that a particular
> directory is a tag and not a branch. This type of knowledge is stored
> in the implementation of the site and not in Subversion itself.
Being in a directory "/tags/" conveys the meaning pretty well - could
explain why this should be considered a shortcoming?
> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can checkout
> the tag's directory, make modifications, then commit those changes.
> This means an admin could create a REV1.0 tag directory, and have
> users change it without the administrator's knowledge.
Hook scripts can resolve this item without any changes to Subversion itself.
> There is also no way a tag can be used in Subversion's "svn" sub
> commands. For example, in order to compare the current version of
> foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
> version of foo elsewhere and use an external diff command, or find out
> the revision number that was used to create REV1.2, then plug that
> into the diff command. It would be much easier if you could do this:
>
> $ svn diff -rREV1.2 foo.c
Then, perhaps we need to design an acceptable shorthand for:
$ svn diff url://to/repository/tags/REV1.2/foo.c foo.c
> we'd like to see the following features implemented:
>
> 1). There should be a fairly easy to use "svn mklabel" command that
> creates the label.
c.f. "svn cp"
> 2). Anyone should be able to create a label, but only the Subversion
> administrator should be able to change it. This would include editing
> the label, moving it, renaming it, and even deleting it.
Answerable right now using hook scripts.
> 3). You need to be able to list the various label names created.
c.f. "svn ls url://to/repos/tags"
(I'm aware that tags are presently quite lacking in their query-ability -
but in that case, perhaps we should enhance tags, rather than create a new
similar concept)
> 4). Most importantly, all of the sub commands for svn and svnlook that
> take the --revision parameter must understand the concept of labels.
> That is, I should be able to specify a label rather than a revision
> number, and Subversion automatically does the right thing
But anything which can take an URL, can refer to a tag.
> Any thoughts about labels vs. tags?
I think the overriding summary thought has to be "Is there really anything
labels could do, which (suitably enhanced) tags could not?".
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Subversion "labels" vs. "tags"
Posted by David Weintraub <qa...@gmail.com>.
Let's try this again with the correct subject line...
Over on the Subversion User List, there has been quite a discussion on
the problems with "tags" and the need for a true object type called a
"label". This discussion can be found at:
<http://subversion.tigris.org/servlets/BrowseList?listName=users&by=thread&from=319767&to=319767&first=1&count=115>
<http://tinyurl.com/d4ql8>
After extensive debate, we felt it was time for the Subversion
developers to get involved in our discussion.
We agree that tags have several short comings:
Tags are not first class objects in Subversion -- just another
directory. It is up to the administrator to know that a particular
directory is a tag and not a branch. This type of knowledge is stored
in the implementation of the site and not in Subversion itself.
Once a tag is created, there is no real mechanism built into
Subversion that protects the sanctity of that tag. A user can checkout
the tag's directory, make modifications, then commit those changes.
This means an admin could create a REV1.0 tag directory, and have
users change it without the administrator's knowledge.
There is also no way a tag can be used in Subversion's "svn" sub
commands. For example, in order to compare the current version of
foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
version of foo elsewhere and use an external diff command, or find out
the revision number that was used to create REV1.2, then plug that
into the diff command. It would be much easier if you could do this:
$ svn diff -rREV1.2 foo.c
On the Subversion User's list, we've discussed several ways to
implement tags which I'm not going to go through here since that is
really up to the developers. We do agree that we'd like to see the
following features implemented:
1). There should be a fairly easy to use "svn mklabel" command that
creates the label.
2). Anyone should be able to create a label, but only the Subversion
administrator should be able to change it. This would include editing
the label, moving it, renaming it, and even deleting it.
3). You need to be able to list the various label names created.
4). Most importantly, all of the sub commands for svn and svnlook that
take the --revision parameter must understand the concept of labels.
That is, I should be able to specify a label rather than a revision
number, and Subversion automatically does the right thing
We also discussed several ways labels could be implemented: As a
special property on files, as an alias to a particular revision
number, and as a special instance of a "tag". However, we realize the
question of how labels should be implemented is really up to the
developers.
Any thoughts about labels vs. tags?
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by David Weintraub <qa...@gmail.com>.
Over on the Subversion User List, there has been quite a discussion on
the problems with "tags" and the need for a true object type called a
"label". This discussion can be found at:
<http://subversion.tigris.org/servlets/BrowseList?listName=users&by=thread&from=319767&to=319767&first=1&count=115>
<http://tinyurl.com/d4ql8>
After extensive debate, we felt it was time for the Subversion
developers to get involved in our discussion.
We agree that tags have several short comings:
Tags are not first class objects in Subversion -- just another
directory. It is up to the administrator to know that a particular
directory is a tag and not a branch. This type of knowledge is stored
in the implementation of the site and not in Subversion itself.
Once a tag is created, there is no real mechanism built into
Subversion that protects the sanctity of that tag. A user can checkout
the tag's directory, make modifications, then commit those changes.
This means an admin could create a REV1.0 tag directory, and have
users change it without the administrator's knowledge.
There is also no way a tag can be used in Subversion's "svn" sub
commands. For example, in order to compare the current version of
foo.c with foo.c in revision REV1.2, you have to either copy REV1.2's
version of foo elsewhere and use an external diff command, or find out
the revision number that was used to create REV1.2, then plug that
into the diff command. It would be much easier if you could do this:
$ svn diff -rREV1.2 foo.c
On the Subversion User's list, we've discussed several ways to
implement tags which I'm not going to go through here since that is
really up to the developers. We do agree that we'd like to see the
following features implemented:
1). There should be a fairly easy to use "svn mklabel" command that
creates the label.
2). Anyone should be able to create a label, but only the Subversion
administrator should be able to change it. This would include editing
the label, moving it, renaming it, and even deleting it.
3). You need to be able to list the various label names created.
4). Most importantly, all of the sub commands for svn and svnlook that
take the --revision parameter must understand the concept of labels.
That is, I should be able to specify a label rather than a revision
number, and Subversion automatically does the right thing
We also discussed several ways labels could be implemented: As a
special property on files, as an alias to a particular revision
number, and as a special instance of a "tag". However, we realize the
question of how labels should be implemented is really up to the
developers.
Any thoughts about labels vs. tags?
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 20, 2005, at 1:50 PM, Ben Reser wrote:
>
> Please test and send me your signatures. Thank you.
>
Tested all 6 combinations on Windows. Here's my sig for the .zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQBCjpTSU0gaaOxrUVYRArPOAJ9CXTlkESjF7qsFGdUZ4qAf9XHABwCgro/6
9D1hI7O+H5LX8P3FE3FNG9w=
=Ukdg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by Mark Phippard <Ma...@softlanding.com>.
Here is my signature for the Windows zip file. I verified
that the content is identical, and that it passes win_tests.py over
all six combinations of RA layer and FS back end.
I am not a full committer so this is a non-binding vote.
subversion-1.2.0.zip.asc:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
iQEVAwUAQpHdcxWeN4F91mdnAQIDvAf/QEE46+tm2jMNOD55DfZygiOxIVd701Gh
ZcXq96tob5mAiVwE8kql7KLQSolU5mIuuZejS8ynrMCTaOhoje72hbDvrMwn+N6V
XDyDPshiOaQdl2YGsbZVi+qqOCAmHTDGW+YjX8+fZ0yhc9TLVNnT9on00xr2VnWN
9f3TlieAEArnusqPFsY3EbrIACN+nXQf0nlOW1kC93VszkvnOxkEQR9j5HZAgH8S
P5rlZAO8p8n6i3hvVDgzTHxLf9crFrNeyB4Iys+Od2l2SHGWbo+qplVEtzocux0S
WwnuO6DXYKupFIgdUMfUg13/J+ATWAt3r7e0d3RGSdxwTm4UAbDGEQ==
=BIxd
-----END PGP SIGNATURE-----
Here is my public key info.
pub 2048R/7DD66767 2005-05-12 Mark Phippard (SoftLanding Systems)
<ma...@softlanding.com>
Key fingerprint = EAF4 5239 AF08 D762 539A 13D5 159E 3781 7DD6 6767
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Please test and send me your signatures. Thank you.
All six RA/FS combinations tested on Debian GNU/Linux (sarge).
subversion-1.2.0.tar.bz2.asc:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.92 (GNU/Linux)
iD8DBQBCj73svJ27E9sAokgRAp0bAKCxQgOF/R8Q4517GZ9fhOMP6JjJ9wCgkt9F
JV9ssEuhq6Pyuos3MV3yObs=
=wWap
-----END PGP SIGNATURE-----
subversion-1.2.0.tar.gz.asc:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.92 (GNU/Linux)
iD8DBQBCj732vJ27E9sAokgRAozEAKCIOomr/aWxTjQZ+BILhBKOYvlh6QCeMjBp
naTFmpQY+naFGkZoJL3lxLw=
=gwDR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.2.0 tarballs up for testing/signing
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-05-20 11:50-0700, Ben Reser wrote:
> Cut from r14790 on 1.2.x branch.
>
> sha1sums:
> 6dcafbd5a4636e9962cca06d93267028143f303d subversion-1.2.0.tar.bz2
> bee1021a1dd9fedc6aae4f59395dca8610b6830a subversion-1.2.0.tar.gz
Hello Ben,
Here is my signatures for 1.2.0. I have tested following:
- make
- make swig-pl
- make check-swig-pl
- make javahl
- make check-javahl
- make swig-py
- make install
- make check in ({fsfs, bdb} X {ra_local, ra_svn, ra_dav})
- make install-swig-py
- make install-javahl
Thanks!
BR, Jani
--
Jani Averbach