Good day all,
I am in trouble. I have convinced my project managers that we should
try out Subversion in a project. It all works fine, especially for
the programmers. The "trunk-tags-branches-model" works excellent for
us when working on the source code tree.
However, the project managers keep asking about certain functionality
(see below), and I can't figure out what to tell them.
I am considering to file this as an RFE, but I assume other people
have encountered this as well. How do you people "out there" solve the
following problem?
==================
Here we go. People (our project managers) would like to be able to do
(something similar to) the following:
1) Enter some directory in the (trunk of the) project tree, where some
document (currently of interest) resides:
% cd /home/myname/myproj/Requirements/UseCaseDoc
% ls
doc.tex image.gif makefile
2a) Set an (unversioned) textual "label" (or "alias" or "tag") for any
given repository revision number -- for any item in the tree (a
directory or a file). In effect, such a "label" would work as a
*textual alias* for the repository revision number, an alias that is
"in scope" for a certain item only -- not the whole repository. I have
invented some mock svn-subcommands to illustrate. For example:
% svn status -u
Status against revision: 354
% svn labelset "VERSION 0.2.0" -m "after first review meeting" .
Setting label "VERSION 0.2.0" on revision 354 of directory "."
% svn labelset -r201 "VERSION 0.1.9" -m "performed spellcheck" .
Setting label "VERSION 0.1.9" on revision 201 of directory "."
2b) For any given item (file or directory), list the (whole)
"label-history" of the item.
% svn labellist .
rev label comment
---- ------------- ----------------
r354 -- VERSION 0.2.0 -- after first review meeting
r201 -- VERSION 0.1.9 -- performed spellcheck
r121 -- VERSION 0.1.0 -- initial version
2c) Use the label (just as with ordinary repository revision numbers)
to do svn update:
% svn update --label "VERSION 0.1.9" .
U doc.tex
U image.gif
U makefile
Updated to revision 201, with label "VERSION 0.1.9".
====================
There might be a number of solutions to this. I have been able to
figure out the following, but unfortunately non of them suffices:
A) One solution might be to use Subversion "Propoerties" (svn propset,
propget, proplist, propedit), but that will not work for point (2b) or
(2c) above:
% svn propget VERSION -r 1:HEAD .
svn: Revision range is not allowed
B) Another option would be to use the regular
"tagging-by-making-a-copy". But where should the copy (tag) reside? In
this case (with the project managers and their documents), the copy
(i.e the tag) should ideally be stored in a subdirectory of the
current directory, like this:
% cd /home/myname/myproj/Requirements/UseCaseDoc
% ls
doc.tex image.gif makefile
% svn copy . VERSION_0_2_0
svn: Cannot copy path '' into its own child 'version_0_2_0'
but that prints an error message. Any other place for the copy/tag
requires user conventions that must be adhered to, or else we will end
up in tag-chaos.
C) A third option would be to write elaborated log-messages in some
"grep-friendly" way. But this fails for (2b) above.
D) A fourth option is to simulate the "label"-functionality described
above, by *manually* editing a (version controlled) README file:
% cd /home/myname/myproj/Requirements/UseCaseDoc
% ls
doc.tex image.gif makefile README
% cat README
rev label comment
---- ------------- ----------------
r354 -- VERSION 0.2.0 -- after first review meeting
r201 -- VERSION 0.1.9 -- performed spellcheck
r121 -- VERSION 0.1.0 -- initial version
This option (D) is the solution that people here tend to use. It has
some drawbacks and feels very primitive, but still seems to be the
simplest and least error prone method we have tried so far.
Again, what would be the suggested "best practice" for "labeling" or
"tagging" as described above?
Best regards
/Hugo Heden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 3 14:37:17 2004