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
lesmikesell_at_gmail.com
Received on 2013-05-21 19:03:15 CEST