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

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 21 May 2013 12:02:44 -0500

On Tue, May 21, 2013 at 10:54 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> > You mean like 'I expect tags to be immutable out of the box, and have
>> > the VCS not modify them with perfectly normal operations, at least not
>> > without adding -f or something to them'?
>> This sounds like Subversion technically supports tags, just with the caveat that
>> you have to deal with "-f" yourself. From my use case I like that tags are
>> writable by default because that's what I need.
> Although, truly if there was a "tag" command that added metadata to a revision which I think someone showed an example of earlier in this thread, you could still use the "copy" command to get a writeable tag directory like you have now. Frankly, if you are writing to tags it is more like a branch. ;)

We sometimes like to tag a source revision, then add the resulting
binaries after the fact. Conceptually that's not a real change but
more of just the way things work. And we are moving towards letting
Jenkins build from the trunk or a branch, then using a plugin to tag
after a successful build. But,.I still miss the way CVS let you
easily 'float' known tag names to revisions (even mixed, cherry-picked
workspaces) to target subsequent operations like your nightly build or
the rollback version as you advance a deployment. Simulating that by
deleting and making a new tag seems awkward.

Since tag names are what you use by convention, if you wanted
immutable tags you could just as easily use
/path/tags/tag_name_at_revision as the name which will always contain the
same thing. It's not really any harder to pass around than any other
arbitrary name.

   Les Mikesell
Received on 2013-05-21 19:03:15 CEST

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.