svn:externals are exactly what you want. Basically, treat PartA and PartB as
separate projects entirely - think third party libraries - then your ProjectD
just brings together PartA and PartB and adds the glue to concat them together,
using svn:externals to bring in the appropriate versions. Your ProjectD trunk
could bring the trunks for the PartA and PartB, and branches could bring in the
appropriate branches, with tags being locked to specific releases. Though I
would suggest that you also lock trunk to specific releases of the externals
too, for stability; but that's a project admin's decision.
Ben
----- Original Message ----
> From: Geoff Hoffman <geoff.hoffman_at_jawa.com>
> To: users_at_subversion.apache.org
> Sent: Thu, September 9, 2010 5:12:52 PM
> Subject: Re: Two trunks in one repository?
>
> SVN won't care, but our IDE may not like it like that. The only reason I
>brought up svn:externals before is if PartA and PartB are already in SVN as
>their own repos (or trees under one repo) then ProjectD doesn't want a copy of
>those projects code, but rather a reference to them.
>
> Thus, on ProjectD you'd have
>
> svn propset svn:externals PartA ProjectA/tags/tagA1 PartB ProjectB/tags/tagB1
>
> When you commit and update this, new folders appear (PartA and PartB) from svn
>checkout of tagA1 and tagB1 respectively. Update those tags or change externals
>to new tag, and your ProjectD gets the update at next svn up.
>
>
>
> ----- Original Message -----
> From: "Tech Geek" <techgeek12345_at_gmail.com>
> To: "Erik Andersson" <kirean_at_gmail.com>
> Cc: "Geoff Hoffman" <geoff.hoffman_at_jawa.com>, users_at_subversion.apache.org
> Sent: Thursday, September 9, 2010 1:23:27 PM
> Subject: Re: Two trunks in one repository?
>
>
> I am thinking something like this:
>
> ProjectD
> ProjectD/PartA/trunk
> ProjectD/PartA/tags
> ProjectD/PartA/branches
> ProjectD/PartB/trunk
> ProjectD/PartB/tags
> ProjectD/PartB/branches
>
> Beleive me or not in our scenario the code of Part A and Part B never gets
>merged at any point. The only common part is that at the end of each release of
>Part A and Part B their output file is concetenated into a one single file
>which is then programmed on a hardware part by an external tool.
>
>
> So for a scenario like that I would like to keep it very simple. Any feedback
>or comments regarding the above structure?
>
>
> Thanks!
>
Received on 2010-09-10 00:03:33 CEST