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

RE: Best practice for moving folders around?

From: Cooke, Mark <mark.cooke_at_siemens.com>
Date: Wed, 12 May 2010 10:32:58 +0100

Many thanks Ulrich for your input...

> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt_at_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
Received on 2010-05-12 11:33:34 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.