Best practice for moving folders around?

["Cooke, Mark" <ma...@siemens.com>]

Dear List,

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).  This was cp'd to
'tags'/tag1.  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

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.

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

I welcome your suggestions on the best solution.  We are hosting svn
1.6.6 on windoze server (via apache) and using latest tortoise from
windoze clients.  I have to admit that I've used svn pretty much as a
solo developer for several years now and never needed to branch/merge.
Now I find myself as admin for several small teams across departments
and in need of guidance.

Many thanks,

~ mark c

Re: Best practice for moving folders around?

[Les Mikesell <le...@gmail.com>]

Cooke, Mark wrote:
>
> Good idea, I Have no hooks setup as yet, I will look into this.
> Otherwise, yes, it is mainly an education issue...

Note that making mistakes is fairly normal, so one thing you should work out is 
a scheme to track the tags that you care about.  You probably want some 
human-friendly name and numbering scheme where you copy the trunk or branch 
versions you expect to be interested in - and you should expect some of these to 
have various problems and you'll just ignore them later.

On the other hand if you are just getting started and want to clean up, you 
could probably svnadmin dump the repository, svnadumpfilter including only 
tags2, then make a new repository with trunk/tags/branches directories and 
svnadmin load your history with trunk as the parent directory.

-- 
   Les Mikesell
    lesmikesell@gmail.com

RE: Best practice for moving folders around?

["Cooke, Mark" <ma...@siemens.com>]

Many thanks Ulrich for your input...

> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com] 
> Sent: 11 May 2010 16:33
> 
> 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.
> 
We converted the whole archive using vss2svn (this one:
http://code.google.com/p/vss2svn/ there seem to be 2 projects with that
name!) which worked reasonably well.  However, we decided to split the
projects into separate repos (with associated Trac sites) and the effort
to dumpfilter all the bits out was deemed too much for the little gain.
So we just keep the import available read-only for reference.

> > 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.
> 
Good idea, I Have no hooks setup as yet, I will look into this.
Otherwise, yes, it is mainly an education issue...

> > 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.
> 
...development has been committed...

> 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.
> 
...this case applies, but...

> 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.
> 
...no other changes to 'trunk' have occurred...

> > 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.
> 
I agree with all your points, so I propose we will (a) move the
offending tag2 to 'branches', relocating the wc to the new location, (b)
merge the changes into 'trunk' to reinforce the idea that that should be
where development continues and then (c) create a new tag2 from the
trunk.

> > 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.
> 
Thanks for the useful guide, we will have a go and, hopefully, report
success.

> Good luck!
> 
Once again, many thanks for your time.

~ mark c

Re: Best practice for moving folders around?

[Ulrich Eckhardt <ec...@satorlaser.com>]

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