Recently I was very surprised when I was asked to commit my changes into a TAG.
So I asked:
- You mean branch?
- No, Tag!
- ???
I always thought that a tag is just a 'marker' that marks a point in a branch and it doesn't branch the code. So what does committing to a tag actually mean? How to commit something to a tag without affecting the branch it was created for?
The answer for those questions can be found in TortoiseSVN documentation explaining what tags and branches actually are from technical perspective:
Tags are typically used to create a static snapshot of the project at a particular stage. As such they not normally used for development - that's what branches are for, which is the reason we recommended the /trunk /branches /tags repository structure in the first place. Working on a tag revision is not a good idea, but because your local files are not write protected there is nothing to stop you doing this by mistake. However, if you try to commit to a path in the repository which contains /tags/, TortoiseSVN will warn you.
Although Tortoise actually allows you to commit into a tag you should never do that! It actually branches the code and makes the code repository messy! After such operations there are actual branches under tags structure. I can't imagine what merging such branched tag with its original branch would actually mean?
But what if you need to add changes to the tagged release (a.g. patches)? Here is the proper way to solve such problem:
It may be that you need to make further changes to a release which you have already tagged. The correct way to handle this is to create a new branch from the tag first and commit the branch. Do your Changes on this branch and then create a new tag from this new branch, e.g. Version_1.0.1.
Now when I understand the problem better I'm just wondering why TortoiseSVN (other tools probably too) allows such operation (with warning). Are there any situations where it would be necessary?
5 comments:
In case of a very small change, you might decide to check in to the tag instead of repeating the whole procedure: create branch, check in, create a tag.
Basically, it's a compromise between what's recommended and what's better in real-life problem.
If one is stubborn they can use a tag instead of trunk. From SVN perspective there's no difference. However if you see such things in a project it's not really a thing to be proud of ;)
@Jaroslaw, I can't agree with you: In my opinion for even the smallest change a new branch should be created. This way a tag remains what it is (i.e. a tag, not a branch) and there is no mess in your repository.
Wouldn't go for such compromise.
Good Afternoon
Awesome post, just want to say thanks for the share
Good point, though sometimes it's hard to arrive to definite conclusions
Post a Comment