Why shouldn't you commit on a tag

Question

I'm looking for arguments to convince an customer that he should never commit changes to a tag once it is created.

Common sense appears to be no valid argument so I need something more substantial.

Solution 1

Tags exist as copies of the sourcecode at a fixed point in time - regardless of whatever changes you might make to the Trunk or any Branch folders, you'll always be able to go back to the code as it was when the tag copy was created.

If you're committing to tagged copies, they no longer represent the source at the point the copy was created - so there's little point having them. Your client should be committing to the trunk, or to branches.

Solution 2

Users who are using the project may be using a certain tagged version of your code. They know their code works with the tag you've specified and will happily release based on this assumption. If you change the tag, then the user's code may break. A tag is literally that - it is a stable milestone on which other user's can consider set in stone.

Also, if there is more than one developer on the project, they'll be working on trunk. When they update, they won't get the changes that were made on the tag which will cause a huge merge problem.

Solution 3

Old post, but as other might still read it I'll add my two cents:

Previous answers all rely on the common sense you say the client is not responding to. Try this story instead: "A tag is like taking a family picture at a wedding. You wouldn't pull out your permanent marker to add aunt Lisa to the picture, would you? If you want to paint, use a piece of paper instead. (=branch)"

As a side note it'd be interesting to know why the customer wants to commit to the tag. I find it much easier to argue when knowing what the counterpart is trying to achieve, and the needs behind that.

Solution 4

Tag should point to some existing revision in time. You're basically giving this revision a name, i.e. tag. In SVN, tag is just a copy in /tags directory, so commiting is possible, but that's just an implementation detail. Nothing prevents you from commiting, but it's unusual, and people using the tag may be confused what exactly this tag represent ... original revision when tag was created or new changes. In the end, it's all about communicating your intent.

In other systems, tags are just pointers to specific revision. You can create new branch from tagged revision, but tag remains pointing to original revision.

Solution 5

When tagging a version, it can be hard to predict if you will later need to go back to that version and make changes. Sometimes you wish you had made a branch instead of just a tag, but most of times a branch is overkill.

Maybe you can convince your customer to take another approach, between committing on a tag and make a branch (which a lot of people fear).

First make a local copy of a tag, then make the necessary changes (locally), and commit the result as a new tag. If the new version requires several commits, you can give the new tag a draft name—just to make sure no one mistakes this tag for a finished version—and when all commits are made, rename the new tag to a final name. (I believe SVN allows renaming tags, although I've never done it.)

View more solutions