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

Re: question about multi-level trunk/branches/tags structure

From: Olaf Conradi <oohlaf_at_gmail.com>
Date: 2005-01-08 15:15:31 CET

On Sat, 8 Jan 2005 05:56:08 -0500 (EST), Robert P. J. Day
<rpjday@mindspring.com> wrote:
> and so on. but what if one of these "projects" had a subdirectory
> that someone might want to branch or tag? could i end up with
>
> proj1/
> trunk/
> dir1/
> dir2/
> trunk/
> branches/
> tags/
>
> and perhaps even more further down.

Just create all branches within the toplevel branch of the project.
So a branch of dir2 to implement a feature would be created within
proj1/branches.

Like:

proj1/
  branches/
    proj1-feature/ branch of trunk for a particular feature,
contains dir2 only
      dir2/
    proj1-1.x/ stable bugfix branch for version 1.x
      dir1/
      dir2/
  tags/
    proj1-1.0/ tagging version 1.0 of proj1 from branch proj1-1.x
      dir1/
      dir2/
    proj1-1.1/ tagging version 1.1 of proj1 from branch proj1-1.x
      dir1/
      dir2/
  trunk/ latest development of proj1 headed for version 2
    dir1/
    dir2/

All development for some feature of dir2 takes place in
branches/proj1-feature/dir2/
and when at some point you notice you need stuf from dir1 for that
feature you can always add dir1 to proj1-feature.

But usually proj1-feature is created as a full cheap copy of trunk,
even if dir2 is the only one to be modified. But do whatever you feel
comfortable with.

This keeps your trunk clean. I wouldn't nest the conceptual
directories branches, tags and trunk to keep check outs simple.

 -Olaf

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jan 8 15:17:43 2005

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.