[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Cleaning up tags and branches

From: Rush Manbert <rush_at_manbert.com>
Date: Tue, 01 Apr 2008 16:25:09 -0700

Hari Kodungallur wrote:
> On Tue, Apr 1, 2008 at 2:19 PM, Rush Manbert <rush_at_manbert.com> wrote:
>
>
>>I have a repository that was migrated from CVS to SVN with the cvs2svn
>>script. During the migration, quite a few branches and tags were created.
>>
>>Now other people are going to start using the repository, and I have
>>been asked whether we can delete the branches and tags created during
>>the migration. Being quite paranoid about stuff like that, I said no.
>>However, I think that it would be okay to create a new directory
>>/branches/cvsBranches and copy everything that is currently in /branches
>>to there. I would also create /tags/cvsTags and copy everything
>>currently in my tags directory to there.
>>
>>Nothing currently in /tags or /branches is useful going forward, but
>>they helped greatly to set up my vendor source branches after the merge
>>and I'm scared to just get rid of them. At the same time, we would like
>>to start with "clean" /tags and /branches directories and enforce naming
>>conventions for their use.
>>
>>I don't see any downside to moving the directories as outlined above.
>>Does anyone else?
>
>
>
>
> Please note that when you remove the directories, they are not removed
> forever. They stay in your repository. If you delete the entire tags or
> branches directory and at a future date wish that you wanted to see the
> deleted code, you can go back to the version of the repository before it was
> deleted and revive them.
>
> You can remove the tags and branches and commit the changes, say revision
> 1000. And you keep on with your development and after revision 5000, you
> want to look at the tags that were deleted. You can just use the
> URL_at_999syntax to go back to that revision and possibly copy it to a
> new branch or
> check it out as a working copy etc. The only gotcha is: how do you know when
> (which revision) you deleted the tags and branches so that you can go back
> to it. Judicious use of 'svn log' coupled with a good commenting policy
> (clearly indicate in your message what you are deleting and why) can ease
> that pain.
>
> Alternatively you can also copy the existing tags and branches to
> tags/cvsTags and branches/cvsBranches. From the point of view of the
> repository (size, performance etc), this is pretty much the same as deleting
> the tags and branches.
>
> Basically, I guess it all depends on what you prefer :-)
>
> Regards,
> -Hari
>

Hi Hari and Paul,

Thank you both for your replies. As you have both reminded me, those
branches and tags aren't ever gone from the repository. I was busy
examining the trees and neglected to see the forest around me.

It hadn't occurred to me that I could copy a directory across repository
revision levels, even though I probably read it somewhere. Now I have
done some experiments and I see that I can delete a tag directory from
the HEAD, but copy it back to the HEAD (at revision+2 from where I
started) by browsing the earlier repository revision and copying from
there. I also see how the command line supports this. I feel much better
about deleting all those old tags and branches now.

Gosh, now I feel like I should clean off my desk too. Clean out the
garage at home. Quit using vim in favor of a squeaky new modern GUI
editor. Well, maybe not the vim thing. ;-)

Thank you both again. Your comments were very helpful.

Best regards,
Rush

P.S. Hari - sorry for the reply just to you. I hit the wrong button.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-02 01:25:29 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.