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.hoff...@jawa.com>
> To: users@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"  <techgeek12...@gmail.com>
> To:  "Erik Andersson" <kir...@gmail.com>
> Cc: "Geoff Hoffman"  <geoff.hoff...@jawa.com>, users@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! 
> 

Reply via email to