You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mattius McLaughlin <Ma...@pmc-sierra.com> on 2010/01/07 00:18:44 UTC

Union of Multiple Branches

Hi All,

  I understand this is not common workflow, but I'd like to know if 
there is a simple way to accomplish this goal before I start scripting a 
solution.

  Some background: one of the requirements for my organization moving to 
subversion was the ability to create tags/branches that contain a subset 
of files on the trunk.  We accomplish this by creating the tag/branch, 
and svn rm'ing any files that aren't required until we've arrived at the 
desired fileset.  We work with very large files and need to use subsets 
of files to avoid lots of disk usage/network traffic.

  Some users have asked if it is possible to check out multiple tags 
into the same workspace.  That is, if we have tag a and tag b with files 
independent of one another but common directories, is it possible to 
check out a workspace that is an amalgamation of tag a and tag b.  Merge 
doesn't get me what I need because the merge replays all of the file 
deletes that were used to generate a subset tag.

  So my question is: is there a way to get two branches/tags to live in 
the same workspace?

Thanks,
--Mattius

Re: Union of Multiple Branches

Posted by Johan Corveleyn <jc...@gmail.com>.
Just throwing in my 2 cents: another way to create such "partial
branches" is by performing an "svn copy" with multiple sources
directories (all the ones you want in your branch), all in one commit
directly on the repository. That way, you don't have to delete
anything afterwards (you have only branched what you want).

Say your repository looks like this:
/trunk/proj1
/trunk/proj2
/trunk/proj3
/trunk/proj4
/branches

You want to create a branch (say rel1.0) with only proj2 and proj4 in
it, you can do it like so:
svn copy --parents $REPO_URL/trunk/proj2 $REPO_URL/trunk/proj4
$REPO_URL/branches/rel1.0

This makes use of a little known feature of "svn copy", namely that
you can specify multiple source paths:
    usage: copy SRC[@REV]... DST

Note that you need the --parents option, which will automatically
create the rel1.0 directory if that doesn't exist yet.

I have no idea how to do this with TortoiseSVN though, but maybe it's
possible with the Repo-browser, multi-selecting your sources paths and
the copying them...

Anyway, that probably doesn't answer your real question, which is how
to combine two such branches into one working copy. Sorry, I have no
ideas there...

Regards,
Johan

Re: Union of Multiple Branches

Posted by Mattius McLaughlin <Ma...@pmc-sierra.com>.
Rob van Oostrum wrote:
> "Cleaning up" your branches is a bad idea. It just creates that much 
> more administrative overhead. Not to mention having to tiptoe around 
> the deletions when merging the branch back to trunk, which will affect 
> merge tracking's performance.
>
> What I would do instead is leverage sparse checkouts to only checkout 
> the root folder of the branch, and selectively grab the directories 
> you need to work with.
>
> You can create mixed working copies by using 'svn switch' to point 
> specific folders to their equivalents on specific branches/tags.
>
>
> Regards,
> Rob
>

BRM wrote:

> Your best way to accomplish this is to create another branch (e.g. UNION_A_B) and then use svn:externals to map the two you want to bring together into sub-folders.
> SVN cannot (at least to my knowledge) operate on individual files within a folder in this manner.
>
> So basically:
>
> branch/A
> branch/B
> branch/UNION_A_B
> branch/UNION_A_B/A -> branch/A
> branch/UNION_A_B/B -> branch/B
>
> this will result in any updates to branch/A being seen on update in either location. Likewise with branch/B.
> The user only needs to check out branch/UNION_A_B to get both.
> Additionally, since you are using the svn:externals property, branch/UNION_A_B/A and branch/UNION_A_B/B don't really exist in the repository, but are stored as properties (e.g. absolute minimal storage) that tell the SVN client to checkout those as sub-directories of branch/UNION_A_B - so disk space and network traffic are both minimized as well.
>
> HTH,
>
> Ben
>   
Thanks for the advice. Agreed that this can lead to an administrative 
nightmare, but in general users don't need to make extensive use of 
workspace merging.  This is the first instance where this has come up 
for this type of development.

We use a workflow that involves

1) check out a tag
2) switch any files that need to be modified to the trunk
3) commit changes
4) make a new tag when ready for handoff

The files that we work with are very large and workspaces need to check 
out many dependent projects to create a functional workspace.  It's not 
unheard of to have a workspace that takes 4-6 hours to populate.

  I'd toyed with the idea of using externals in the workspace, but as 
mentioned svn doesn't support mixing workspaces like this.  Having the 
data in a separate folder via an external doesn't quite work for the 
designer because they need the files from

My thinking now is that the only way to do this would be

1) checkout everything from the trunk
2) switch all files in tag a to tag a
3) switch everything else to tag b

But this could mean a 2 fold increase in checkout time, depending upon 
how much the trunk has changed.

Thanks again for the suggestions,
--Mattius

Re: Union of Multiple Branches

Posted by Rob van Oostrum <rv...@gmail.com>.
"Cleaning up" your branches is a bad idea. It just creates that much more
administrative overhead. Not to mention having to tiptoe around the
deletions when merging the branch back to trunk, which will affect merge
tracking's performance.

What I would do instead is leverage sparse checkouts to only checkout the
root folder of the branch, and selectively grab the directories you need to
work with.

You can create mixed working copies by using 'svn switch' to point specific
folders to their equivalents on specific branches/tags.


Regards,
Rob

On Wed, Jan 6, 2010 at 8:23 PM, BRM <bm...@yahoo.com> wrote:

> ----- Original Message ----
>
> > I understand this is not common workflow, but I'd like to know if there
> is a
> > simple way to accomplish this goal before I start scripting a solution.
> >
> > Some background: one of the requirements for my organization moving to
> > subversion was the ability to create tags/branches that contain a subset
> of
> > files on the trunk.  We accomplish this by creating the tag/branch, and
> svn
> > rm'ing any files that aren't required until we've arrived at the desired
> > fileset.  We work with very large files and need to use subsets of files
> to
> > avoid lots of disk usage/network traffic.
>
> That is quite an unusual work flow. And with the efficiency of SVN, you're
> really probably just saving the disk space - may be.
> Network traffic would mostly occur during initial checks; the rest (namely
> updates) is pretty efficient.
>
> > Some users have asked if it is possible to check out multiple tags into
> the same
> > workspace.  That is, if we have tag a and tag b with files independent of
> one
> > another but common directories, is it possible to check out a workspace
> that is
> > an amalgamation of tag a and tag b.  Merge doesn't get me what I need
> because
> > the merge replays all of the file deletes that were used to generate a
> subset
> > tag.
> >
> > So my question is: is there a way to get two branches/tags to live in the
> same
> > workspace?
>
> Your best way to accomplish this is to create another branch (e.g.
> UNION_A_B) and then use svn:externals to map the two you want to bring
> together into sub-folders.
> SVN cannot (at least to my knowledge) operate on individual files within a
> folder in this manner.
>
> So basically:
>
> branch/A
> branch/B
> branch/UNION_A_B
> branch/UNION_A_B/A -> branch/A
> branch/UNION_A_B/B -> branch/B
>
> this will result in any updates to branch/A being seen on update in either
> location. Likewise with branch/B.
> The user only needs to check out branch/UNION_A_B to get both.
> Additionally, since you are using the svn:externals property,
> branch/UNION_A_B/A and branch/UNION_A_B/B don't really exist in the
> repository, but are stored as properties (e.g. absolute minimal storage)
> that tell the SVN client to checkout those as sub-directories of
> branch/UNION_A_B - so disk space and network traffic are both minimized as
> well.
>
> HTH,
>
> Ben
>
>
>

Re: Union of Multiple Branches

Posted by BRM <bm...@yahoo.com>.
----- Original Message ----

> I understand this is not common workflow, but I'd like to know if there is a 
> simple way to accomplish this goal before I start scripting a solution.
> 
> Some background: one of the requirements for my organization moving to 
> subversion was the ability to create tags/branches that contain a subset of 
> files on the trunk.  We accomplish this by creating the tag/branch, and svn 
> rm'ing any files that aren't required until we've arrived at the desired 
> fileset.  We work with very large files and need to use subsets of files to 
> avoid lots of disk usage/network traffic.

That is quite an unusual work flow. And with the efficiency of SVN, you're really probably just saving the disk space - may be.
Network traffic would mostly occur during initial checks; the rest (namely updates) is pretty efficient.
 
> Some users have asked if it is possible to check out multiple tags into the same 
> workspace.  That is, if we have tag a and tag b with files independent of one 
> another but common directories, is it possible to check out a workspace that is 
> an amalgamation of tag a and tag b.  Merge doesn't get me what I need because 
> the merge replays all of the file deletes that were used to generate a subset 
> tag.
> 
> So my question is: is there a way to get two branches/tags to live in the same 
> workspace?

Your best way to accomplish this is to create another branch (e.g. UNION_A_B) and then use svn:externals to map the two you want to bring together into sub-folders.
SVN cannot (at least to my knowledge) operate on individual files within a folder in this manner.

So basically:

branch/A
branch/B
branch/UNION_A_B
branch/UNION_A_B/A -> branch/A
branch/UNION_A_B/B -> branch/B

this will result in any updates to branch/A being seen on update in either location. Likewise with branch/B.
The user only needs to check out branch/UNION_A_B to get both.
Additionally, since you are using the svn:externals property, branch/UNION_A_B/A and branch/UNION_A_B/B don't really exist in the repository, but are stored as properties (e.g. absolute minimal storage) that tell the SVN client to checkout those as sub-directories of branch/UNION_A_B - so disk space and network traffic are both minimized as well.

HTH,

Ben