top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Correct way to undo commit of a tag in SVN?

+1 vote
592 views

My most recent commit was the creation of a tag. I want to delete that tag. Should I reverse merge the commit or simply delete the tag?

If I do a reverse merge I see a tree conflict:

C:>svn merge -c -69  

--- Reverse-merging r69 into '.': 

 C tagsTAG_ 

--- Recording mergeinfo for reverse merge of r69 into '.': 

U . 

Tree conflict on 'tagsTAG_ 

 > local dir edit, incoming dir delete upon merge 

Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: 

What is the best thing to do here?

posted Feb 24, 2015 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

In subversion the usual convention is that tags are never changed after the copy that creates them. That is, they become human-friendly names for a single revision. If you are following that convention, then you should delete the tag if it was not what you intended so you can reuse that tag name.

However, changes tend to be ongoing so you may want to name your tags with some version numbering scheme - in which case you might create a newer tag later and ignore earlier versions. Copies are cheap in subversion and it doesn't hurt to have extra tags as long as the names are not confusing.

answer Feb 24, 2015 by Dewang Chaudhary
Similar Questions
0 votes

We have a situation where a few folks don't use --reintegrate option when performing SVN merge, while others do.
Whats
1- the consequence of not using --reintegrate option; can the feature branch continue to svn merge to trunk the 2nd time and thereafter ?
2- the impact on those feature branches that do use --reintegrate option; from what we read in the manual, that one cannot use this feature branches anymore.

+5 votes

Are there side effects from applying the same svn merge --record-only on the same revision number and a new commit each time it is applied ?

Would there be issues with SVN mergeinfo and/or SVN in general if one keeps applying svn merge --record-only on a revision number repeatedly and commit in a svn merge --record-only followed by commit followed by svn merge --record-only followed by commit and the next cycle begins ? Its not an infinite loop svn merge; it would stop at some point.

+2 votes

We are using svn 1.6 - we tried merging from Trunk to a feature branch using svn merge (automatically). We just found out that some files are not updated with the merges but mergeinfo has already indicated and ci with the messages that those files are merged We like to perform svn merge again using the same revision number from the trunk to the feature branch would svn refuse simply because it was merged "successfully" before ?

+2 votes

We are using svn 1.6 - we tried merging from Trunk to a feature branch using svn merge (automatically). We just found out that some files are not updated with the merges but mergeinfo has already indicated and ci with the messages that those files are merged. We like to perform svn merge again using the same revision number from the trunk to the feature branch would svn refuse simply because it was merged "successfully" before ?

Are there side effects in applying svn merge again on the same revision numbers from the mergeinfo property ?

+1 vote

I have 30 files that I want to merge, but I do not know which would be the easiest and much efficient and save way to do so.
I have the main production line Z and two other branches X and Y. All of the branches are still in production since X and Y are minor releases. Therefor on a time frame they are look this:
Z - trunk, next major releaseY - next minor release (Z - Y = small changes)X - used to make patches for an old release
The idea is that between Z and Y arent so many differences, but between X and Y(or Z) are plenty. There was a fix in the X branch that needs to be back ported into Z and Y. I am using svn merge to merge changes from X to Y, but because of the big differences I think it adds even code that could not be useful in Y, showing as conflicts just a few code blocks/file. which would be the best approach for such a merge?

...