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

Re: Symbolic Names

From: fj <fj_at_effjay.com>
Date: 2007-06-29 23:18:14 CEST

Tad Marko wrote:
>> Yes, when you see that happening, you can point people to this:
>> http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
> And I am already off and changing the subject. Let me come back to it.
> I've been looking over subversion mailing list archives and I keep
> finding lots of lively discussion about labels and symbolic names, often
> times getting into the dev lists. I'm starting to assume that the
> feature that I want is NOT yet implemented, so let me describe
> specifically what I'm looking for and maybe it's just that I'm not
> asking the right question.
> I'd like the ability to drop some sort of a "semi" immutable breadcrumb
> on a particular repository version. I say "semi-immutable" because I'd
> like to be able to move the breadcrumb on purpose, but not accidentally.
> I am very clear about the difference in SVN version numbers as compared
> to CVS, which is obviously a side effect of the support for atomic
> commits. I am fine associating a text breadcrumb with all files in a
> repository.
> I also understand that a tag = branch, or branch-tag in CVS parlance.
> What I need is an analog to a CVS tag. I just want to be able to
> associate human meaningful text with a particular repository version.
> That text will then always relate to THAT version, unlike a SVN tag
> which is a branch and will have its own mutable head.
> My goal is to be able to notate a particular repository version with
> something like "ReleaseCandidate", which will be moved occasionally, and
> "Version 2.4", which will never move. This would be different than a
> "Version 2.4" branch, which may or may not relate to the actual version
> 2.4 depending on if anyone has committed to that branch.
> Yeah, there's a little bit of room for discussion about the discipline
> of developers not committing to a branch vs. their discipline of not
> relocating the semi-immutable breadcrumb. I perceive branches as easy to
> change accidentally, these breadcrumbs as not as easy to change
> accidentally.
> Is there some way to do what I want here, is my thinking wrong, or is
> there a more SVN-like way to do what I'm trying to accomplish? The
> ultimate goal is for a large system, consisting of dozens of SVN
> projects, to be easily kept organized by the build manager. This build
> manager needs to be able to go to a particular project and know which
> version the programmer wants him to promote to testing.
> Thanks,
> Tad
> "Email Firewall" made the following annotations.
> ------------------------------------------------------------------------------
> Warning:
> All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.
> ==============================================================================
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

 From what I've read in the red-bean book, svn doesn't support labeling
like what you're asking for. The closest you might get is to create a
special log message, or perhaps a custom property; at least if my
understanding of SVN's limitations is correct. But I understand what
you're looking for, why you'd want it, and agree it's a valuable
capability, so IMO at least, your thinking is not wrong, or at worst,
you're not alone in being wrong ;-)

I've used StarTeam for the last 6 years or so, and was a StarTeam Admin
for that time as well, plus one of the few who understood and coached on
SCM; both to developers and to non-technical personnel. What you're
describing is very like the "label" feature in StarTeam.

One can create a view label which attaches to **every** object in the
current view, and optionally designate it as a build label (provides
seamless integration with CR's and other objects, since StarTeam is an
integrated system, not just version control).
One can optionally freeze that label, or permit it (restricted by
customizable access rights) to be altered, meaning that one can move it
from one version to another of a given artifact, or attach it to a newly
added artifact if need be.
One can also create revision labels and attach them to an arbitrary set
of artifacts within the current view. Revision labels cannot be used as
build labels.

Both types of labels consist of their "name" string and description. I
am not sure how long the name can be, but it's probably something like
256 characters -- in any event, I never ran in to a practical limit on
the length used for the label name. The description field is obviously
for providing additional information about the significance of the
label; again, I'm not sure of it's maximum data length, but whatever it
was did not prove to be a meaningful limitation in practice.

StarTeam's labeling feature, which as I said is very like what you've
described, is very powerful and flexible. One can create and attach an
arbitrary number of labels such as those I described to any collection
of artifacts; e.g. one could create a view (build) label
"Build2007-06-29-01", which would attach to all artifacts in the current
view at their current revisions., then create a view label "RC1" and
attach it to exactly the same items, resulting in two meaningful labels
for a given view state. An admin, or a user with sufficient permissions,
can arbitrarily CRUD any label. This ability obviates the need to resort
to making entirely separate directory trees (i.e. /tags/ ) just to
capture a specific state of the CM system, the way SVN does, and it
makes it easier to store more detailed information about the particular
state you're trying to preserve. StarTeam labels can also be used in
rolling the state of the display back to any point in history (this can
be done arbitrarily by any user/client, much like any user checking out
or viewing a specific SVN revision in the past).

Since leaving the company where I was using StarTeam, I've delved into
SVN. There's certainly lots of positive buzz about it and it seems a
credible tool, though by design it's limited to being a versioning tool
only. However, I consider SVN's approach of **having** to capture
special states such as you describe in your "ReleaseCandidate" and
"Version 2.4" example earlier by creating tag and/or branch directories
to be a weakness. If it were to come to it, I would vote in support of
adding a feature to SVN like the labeling you describe and that I've
seen implemented in StarTeam.

Of course, I may be incorrect in my understanding of SVN's functionality
-- I'm not very experience with it yet -- and it may prove that one can
effectively accomplish much the same ends using SVN's property-setting
capabilities. I'd welcome anybody correcting any errors in my
understanding of SVN.

- fj

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 23:19:04 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.