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

RE: Similating "label" feature in Subversion?

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-08-28 16:23:07 CEST

> -----Original Message-----
> From: Jean-Claude Antonio [mailto:jcantonio@arcetis.com]
> There are 2 ways you can achieve this.
> With Branches
> projects
> /trunk
> /branches
> /2007-05-01; Mini-effort on feature A
> /2007-05-15; Mini-effort on feature B
> /tags
> You can always determine the branchpoints (the revision of
> the creation of you branch) of your branches :
> by using svn log --stop-on-copy
> so you can use the svn update -r branchpoint
> Or if you want you can create Tags.
> - Create your branch, then create you tag (make it then RO by
> a script or with authorization)
> - Start develop in your branch.
> Remember that svn copy is cheap.


> then use svn co path_to_tag_name to go back to.
> Jean-Claude
> Bicking, David (HHoldings, IT) a écrit :
> >
> > Thank you for your reply. What you suggest is to use the
> revision. However, I am talking about labeling a revision
> with a human-readable, searchable text fragment. Some SCM
> tools permit labels on individual files at specific
> revisions, though these systems usually keep revisions per
> file, not per repository.


> From: Dave Grundgeiger [mailto:dave.grundgeiger@codenouveau.com]
> Hi David. I think I'm missing something. If you create a tag
> at each of the above milestones, giving the tag the desired
> human-readable name, then your tags folder contains the list
> that you show above, and you can revert to any tag at will.
> Is there additional behavior that you need?
> Dave

Thanks guys. I think it is safe to say that what I seek is not available and probably won't be added to Subversion, but the existing techniques, as you describe, get the basic job done. Dave, to your point, "revert to any tag at will", is different as you describe it from what I was seeking. What actually happens in your revert is a "reverse-merge" as I call it, which puts at the tip the same code that was in the tag. I was looking at it from a different angle: right-click the label, choose "rollback", and essentially delete all revisions after that label in the _codeline_ that was labeled.

If we use Subversion we simply have to come to grips with a few points:

1. If we tag liberally, we will have a very large repository directory (but fairly small usage of repository space).

2. "rollback" as usually understood does not exist in Subversion. A similar outcome is achieved by a kind of "commit in reverse order". Unlike "traditional rollback", this preserves all changes (in both directions) in history and is slightly more complicated to execute.

3. To tag individual files, we select them and copy them into a tag folder. Hopefully, we would not have reason to do this, because it would require manual duplication of the folder tree (create folder), and I'm not sure if this would be manageable or useful in the repository long term.

4. We cannot look at the history of a file (in a codeline) and see which labels it received, and do a compare between labels. I am unsure how we could get the same result in Subversion w/o much manual work. We would have to determine which tags contained the file and at what revision, then initiate a comparison on the appropriate codeline based on revision numbers. Clunky at best, impossible at worst. In fact, this means we have to make sure we associate individual tags very closely to their branches, which I guess is a best practice anyway. If the label were associated with the file, rather than representing a copy of said file, there would be no danger of any label being listed with the wrong branch, as they are attached to the codeline in question.

This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 28 16:20:38 2007

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

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