Max Bowsher wrote:
>
> If I understand correctly, the main reason for wanting labels is to be
> able to look at a file, and see the tags set on it. This could be
> provided using the existing tags, and a better way to view copy
> history, and this would be much more coherent with the rest of
> Subversion's feature set.
As I understand my project managers, they would want to be able to enter
the (local working) directory of whatever document they are responsible
for -- and work there and *only there*. Typically, they do not want to
need to know anything about our repository design (trunk, tags,
branches) -- "that stuff is for the developers" that work in the
repository every day. Our project managers and sales people usually do
other stuff (taking taxis, eating lunches with people).. Sometimes a few
months will pass between each time such a project management document is
edited by a project manager.
Now, the "put-a-copy-in-the-tags-directory"-model does not seem to
suffice here. I'll try to explain why (using a lot of a long message I
previously posted (May 2004 --
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=10537 )
-- see item (B) way below down there..
===================================================
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 with *tag-chaos*. "User conventions" must be *remembered* and hence is not
suitable for project managers..
(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.
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 Thu Jan 20 10:18:53 2005