On Tue, May 21, 2013 at 10:54 AM, Bob Archer <bob.arc...@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@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 lesmikes...@gmail.com