Re: Revisiting: Question about "labeling" fuctionality

I'd say go for propset/propget and implement the "labeling"
functionality with an external client (at least for now). It's not the
easiest solution ever, but it should still work.

---
Rami Kayyali
On Thu, 20 Jan 2005 10:16:27 +0100, Hugo Heden <heden@foi.se> wrote:
> 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
> 
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org