subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael P. Reilly" <arc...@gmail.com>
Subject Re: Need advise for branching/tagging/trunking an entirely new revision of trunk
Date Sat, 14 Jul 2012 01:42:33 GMT
On Fri, Jul 13, 2012 at 8:56 PM, Daevid Vincent <daevid@daevid.com> wrote:

> We have been building and maintaining our project for 18 months in SVN
> "/mycompany/m.example.com/trunk".
> Current revision is @r3881.
>
> Now we want to re-design. This includes directory structures, files, code,
> etc.
>
> I was thinking we just want to shove everything that is now 'trunk' into a
> 'branch' and start with a clean slate in 'trunk'. Everyone will re-checkout
> and we will re-export on the production server too. We are only 3
> developers, so impact is minimal whatever we decide.
>
> [a] is this advisable? if not, what is the proper way to do this?
>
> [b] what would be the SVN commands to accomplish this?
>
> [c] we've never done any branching or tagging before. We simply use SVN for
> the very basics to commit, revert, archive/backup, export/checkout, etc...
>
> We're running Subversion 1.6.16 if that matters.
>
>
What I usually do and advise, even when just myself, is to copy the trunk
to a 'restructure' branch, make the changes there, then if bugs need to be
fixed on the trunk, they can be and then merged to the restructure branch.
 Then when completed, you merge everything back to the trunk.  Files that
you've moved or deleted would be updated on the trunk and you still have
the history of the changes that you made on the branch before the merge.
 For this, you would run:

    svn copy URL/trunk URL/branches/restructure-20120713
    svn checkout URL/branches/restructure-20120713 restructure-branch
    {do your restructuring in restructure-branch}
    svn merge URL/branches/restructure-20120713 trunk
    svn comit -m "Product code restructuring" trunk

There are very few instances where I do a 'move' to replace the trunk.
 That breaks a lot of continuity (history is broken, for example).

Even if you are starting from scratch, I still advise the process above:
 Copy -> Restructure -> Merge.  In this case, after the copy, there is a
remove of the copy's contents, but that would get propagated to the trunk
on the merge.

  -Arcege
-- 
What comes after the O-nut?
The P-nut
What comes after the P-nut?
The elephant
  *joke told by my sons*

Mime
View raw message