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. **************************************************************************************
