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

Re: making branches, with one more directory level

From: Bart Robinson <lomew_at_pobox.com>
Date: 2006-01-07 22:00:22 CET

Sounds like you have a structure like
 trunk/dir1
 trunk/dir2
 branches/
 tags/

Instead of having branches/newbranch/dir1, I'd flip the last two
components and do:

  trunk/dir1
  trunk/dir2
  branches/dir1/newbranch
  branches/dir1/1.2.x
  branches/dir2/0.9.x
  branches/dir2/0.10.x
  tags/dir1/1.2.1
  tags/dir2/0.9.3
  etc.

that way you only have to svn mkdir once for each dirN, not
everytime you branch.

-- bart

On 2006-1-7 Paul Koning <pkoning@equallogic.com> wrote:
> I have a bunch of different directories under /trunk, only a few of
> which are in regular development.
>
> When branching, I'd prefer not to branch the whole of /trunk, so
> svn copy .../trunk .../branches/newbranch
> is not ideal.
>
> And I don't want to lose the identity of the subdirectory I'm
> branching, so
> svn copy .../trunk/dir1 .../branches/newbranch
> is definitely not good either.
>
> If "svn copy" were like Unix "cp -R" that second copy would have
> produced .../branches/newbranch/dir1 -- but svn doesn't do it that
> way. So I tried:
> svn copy .../trunk/dir1 .../branches/newbranch/dir1
> but that is rejected (branches/newbranch does not exist).
>
> Any suggestions? I suppose I can do it in two steps:
> svn mkdir .../branches/newbranch
> svn copy .../trunk/dir1 .../branches/newbranch/dir1
> which isn't elegant because it takes two steps, but it works. Or I
> could copy .../trunk as a whole and then delete the second level
> directories that I don't want.
>
> paul

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 7 22:02:29 2006

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.