Sean Laurent <email@example.com> wrote on 09/23/2004 02:00:38 PM:
> On Thursday 23 September 2004 12:42 pm, Mark Phippard wrote:
> > Sean Laurent <firstname.lastname@example.org> wrote on 09/23/2004 01:32:21 PM:
> > > There's also the concept of 'labels', provided by software like
> > > and presumably others, which has been mentioned on this list before.
> > > In Perforce, a label is simply way to reference a particular
> > > very similar to the CVS tag mechanism. I know this has been
> > > on the list before
> > To me, this is an advantage of Subversion since the global revision
> > is always present as a means to refer to a specific revision. You do
> > need to create a label to accomplish the same thing. For the same
> > you do not really even need to create a tag. The tag is a convenience
> > item for your own benefit, you do not neeed the tags to get the same
> > results from merges or other operations, as you can also just specify
> > equivalent revision number.
> Well, I have encountered one situation where labels were significantly
> to use than global revision numbers. I worked in a small-medium sized
> company with about 60+ developers/QA that built shrink-wrap software. We
> an automated build system that created a clean build of a product,
> to a server and sent out a notification email (among a myriad of other
> things). After the build completed, the system set a label called
> 'productname_CURRENT' to point to the current revision.
> It was incredibly handy for developers and QA to reference the label,
> of worrying about the revision number... However, this could just as
> be handled by branches/tags in Subversion. The only difference, as
> already pointed out, is really just the mindset ... the nomenclature.
Yes, this has come across the list before. The easiest thing to do is
just delete/recreate the tag.
svn delete url://server/repos/tags/productname_CURRENT -m "Refreshing tag"
svn copy url://server/repos/trunk
url://server/repos/tags/productname_CURRENT -m "Refreshing tag"
As you indicate it is the same feature with a different implementation. I
personally prefer the Subversion approach in that there is no need to
really introduce a special UI or concept for a feature that can already be
accompished. There is a consistency that is really easy to follow once
you grasp it and can set aside what you are used to from other tools.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 23 20:07:45 2004