Re: Best practice for moving folders around?

On Tuesday 11 May 2010, Cooke, Mark wrote:
> Can I ask your suggestions on how best to correct the following
> scenario:
>
> In a new repository we checked a version of the product code into
> 'trunk' (moving projects from VSS, finally).

Just for the record: There are tools that preserve some history, in case you
care.

> This was cp'd to 'tags'/tag1.

A normal tagging operation, okay.

> A new svn user then cp'd 'tags'/tag1 to 'tags'/tag2 and
> checked this out as a working copy:
>
> [project] -> 'trunk'
> 'trunk' -> 'tags'/tag1
> 'tags'/tag1 -> 'tags'/tag2
> 'tags'/tag2 -> (wc)
> (wc) -> 'tags'/tag2

Generally, tags are points in time, they are not intended for development and
should be treated as immutable. There are even pre-commit hooks that enforce
this. However, there is nothing that could stop the user from creating a
working copy of it, only from committing to the repository.

> Several updates later we have discussed the idea of what is a 'tag',
> 'branch' and the 'trunk' and have decided that the development should
> have occurred in 'trunk' (small teams of one or two so no perceived need
> for developer branches) and that we should create a new 'tags'/tag2 for
> the release version.

Yes, development should have taken place either in trunk or in a separate
branch. What you can do now depends on where you are and what you did in
between....

1. If "tag2" was not modified and trunk was not modified either (only local
changes to the working copy), you could switch (svn switch) your working copy
to the trunk and commit from there. You could then delete the tag, there
isn't anything in there that happened anyway.

2. If the trunk was not modified, you could simply delete the project therein
and move "tag2" in its place. Looking at the history, you will see that the
location of the project jumps a bit around though, in case you care.

3. If the developer already committed his changes to the tag, and others
committed to trunk, you should merge those changes into trunk instead. For
that, you first declare the tag as a branch and move it to the "branches"
folder. Then, you simply merge the revisions you want to the trunk. This is
not different from the normal everyday merge that you do from a feature
branch to your trunk and explained in the manual. Note that the developer
must switch (svn switch) his working copy which still points at the tag,
either at the branch or at trunk.

> How do we best achieve this, preserving as much history as possible? I
> can think of several possible solutions:
>
> 1) merge 'tags'/tag2 into trunk, delete 'tags'/tag2 then create new
> 'tags'/tag2 from trunk?
>
> 2) delete 'trunk', move 'tags'/tag2 to become 'trunk', create new tag
>
> 3) I'm sure I could think of worse ideas

Actually, I would suggest merging the changes. Firstly, it documents that the
changes were made in isolation. Secondly, it keeps the continuity of trunk.
Lastly, you get familiar with branching and merging. In any case, you should
delete or move "tag2", because it is not a tag.

> using latest tortoise from windoze clients.

Right-click, submenu, "Merge...". This will guide you through the merge
process. Select "tag2" as source URL and a (clean) working copy of the trunk
as target. Ignoring line ending and whitespace sometimes helps, or merging
smaller ranges. Always merge and commit the root project folder, so you only
have "svn:mergeinfo" property in one place.

Good luck!

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************