Two trunks in one repository?

[Tech Geek]

So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part.

 

But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD.

 

Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for?

 

Thanks!

 

 

[Itamar O]

Maybe I missed something in your scenario,
but I would simply have one trunk with PartA and PartB as sub-directories.

[Jeremy Mordkoff]

On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek <techge...@gmail.com> wrote:
So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part.
 
But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD.
 
Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for?
 
Thanks!

===

Maybe I missed something in your scenario,
but I would simply have one trunk with PartA and PartB as sub-directories.

===
That would depend mostly on your branch and merge patterns. I have a similar situation. Since every branch has both projects in it, every workspace that I use to do merges has to check out both projects, even though no merge ever contains changes to both projects. Quite a pain in the rear. To make it worse, the unix developers use filenames that cannot be created on a windows system (e.g. AUX, COM1, and COM4), so we can't do merges on windows systems at all.

At my top level I have code, vendors and tools. 'code' contains all of our code, the other two are for imports.

So instead of /code/trunk/proj1 and /code/trunk/proj2, I should have /code/proj1/trunk and /code/proj2/trunk. Then I could branch and merge each project separately. But before I do this, I should make absolutelty sure that these two projects have no interdependencies.

AFAIK, branches are just names. So above and beyond fixing up your mergeinfo's (if you have any), this should work just fine.

JLM

[Erik Andersson]

I'm with Itamar

ProjectD

ProjectD/trunk/PartA

ProjectD/trunk/PartB

Also, do read up on svn:externals if you haven't already. 

Cheers / Erik

[Geoff Hoffman]

We have hundreds of trees, each with their own trunk/ branches/ tags/ in one SVN repo. Works great. You may want to look at svn:externals. It may require re-thinking how you're using SVN a bit, but the payoff can be big. Basically you branch or tag anything shared, and load it into ProjectD using

cd ProjectD
svn propset svn:externals local/path path/to/trunk_branch_or_tag

When you change files under path/to/trunk_branch_or_tag and svn up ProjectD, changes come streaming in.

HTH,

Geoff

[Erik Andersson]

On Thu, Sep 9, 2010 at 8:52 PM, Geoff Hoffman <geoff....@jawa.com> wrote:

We have hundreds of trees, each with their own trunk/ branches/ tags/ in one SVN repo. Works great. You may want to look at svn:externals. It may require re-thinking how you're using SVN a bit, but the payoff can be big. Basically you branch or tag anything shared, and load it into ProjectD using

Something like this?

components

components/comp1/[branches|tags|trunk]

components/comp2/[branches|tags|trunk]

components/comp3/[branches|tags|trunk]

components/comp4/[branches|tags|trunk]

components/comp5/[branches|tags|trunk]

projects

projects/projA/[branches|tags|trunk]

projects/projA/[branches|tags|trunk]/comp1 -> components/comp1/[branches|tags|trunk] (with svn:externals)

projects/projB/[branches|tags|trunk]

projects/projB/[branches|tags|trunk]/comp2 -> components/comp2/[branches|tags|trunk] (with svn:externals)

projects/projC/[branches|tags|trunk]

projects/projC/[branches|tags|trunk]/comp3 -> components/comp3/[branches|tags|trunk] (with svn:externals)

projects/projD/[branches|tags|trunk]

projects/projD/[branches|tags|trunk]/comp4 -> components/comp4/[branches|tags|trunk] (with svn:externals)

projects/projD/[branches|tags|trunk]/comp5 -> components/comp5/[branches|tags|trunk] (with svn:externals) 

Cheers / Erik

[Tech Geek]

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!

[Itamar O]

That actually sounds extremely similar to the way I set up repositories for projects in my organization.

Different projects are unrelated, so they reside in separate repositories,

but every project (which is an embedded-device) has software development and FPGA development,

so the layout within the project is exactly what you described:

proj/Software/[trunk,branches,tags]

proj/FPGA/[trunk,branches,tags]

If you case is similar, I recommend using the layout you described, and considering the following points:

* Add proj/Tools (or something like that) to manage the scripts that concatenate the final image etc.

* If you also use SVN to store the resulting images (we do, although it is usually not recommended to keep binary outputs in source control), consider adding proj/Releases for those.

* If you have code-reuse between projects (we have reusable software modules and IP cores) - look into svn:externals and decide how to manage it in your set up. I haven't completed handling this in my set up (still in the process of migrating from VSS..), but I plan to have a dedicated repository for "shared assets" and have specific projects define the assets they use based on absolute svn:externals.

[Tech Geek]

Itamar O, yes you are almost there, I have to say very intelligent guess. I am indeed talking about FPGA development. The only difference is we have a 2 part FPGA on our embedded board. PartA and PartB are both FPGA codes which are developed separately for their respective chips and then later they are concatenated into one single file which is then programmed by the vendor tool on our boards.

 

Concatenation is also not a problem since that is done externally. The only major issue is how do we store (keep in mind SVN principles of trunk, branches, tags) the concatenated file (yes we need to store binary objects too) in my proposed repostiroy structure?

 

I would like this to be as simple as it can be because the developers/users of this system are not very SVN savvy.

 

Thanks!

[Geoff Hoffman]

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" <techge...@gmail.com>

[Tech Geek]

Geoff,

 

I think I am beginning to undestand what you are suggesting.

 

Right now I am in process of implementing this setup. At this point nothing exits - no ProjectD, no PartA and no PartB. So I will try to summarize what I have undestood so far:

 

1. All our SVN repositories lives under the following location:

\\myserver\SVN_Repositories\ProjectA

\\myserver\SVN_Repositories\ProjectB

\\myserver\SVN_Repositories\ProjectC

 

2. Now each of the Project directories - Project A, Project B and Project C are SVN repositories of their own (TortoiseSVN->Create Repository here)

 

3. Now Mr. ProjectD comes along with has two sub-parts - PartA and PartB.

So I create a new repository ProjectD (TortoiseSVN->Create Repository here) under this (correct?):

\\myserver\SVN_Repositories\ProjectD

and then create two directories (with their own tags, branches and trunk) underneath ProjectD (all using SVN commands) like this:

\\myserver\SVN_Repositories\ProjectD\PartA\trunk

\\myserver\SVN_Repositories\ProjectD\PartA\tags

\\myserver\SVN_Repositories\ProjectD\PartA\branches

\\myserver\SVN_Repositories\ProjectD\PartB\trunk

\\myserver\SVN_Repositories\ProjectD\PartB\tags

\\myserver\SVN_Repositories\ProjectD\PartB\branches

 

Note that Part A and Part B are not their individual repositories. They are just directories that live under ProjectD which is a repository.

 

4. Let's say now PartA and PartB code development begings and at some point a tag is created for each of their release:

\\myserver\SVN_Repositories\ProjectD\PartA\tags\REL-1.0

\\myserver\SVN_Repositories\ProjectD\PartB\tags\REL-1.0

 

Now let's say the output of Part A - PartA.xcf and output of Part B - PartB.xcf are concatenated into a file called PartAB-R1.xcf.

 

My questions:

Q1. At this point I would somehow like to store this file (PartAB-R1.xcf) into my SVN repository (ProjectD). What would be an ideal location (logically) to store such a file. Should I be doing any kind of merging from tags (REL1.0) of PartA and PartB to create another node called "Combined-REL-1.0" or something like that. I would like to avoid this if possible.

 

Q2. Also when somebody checks out ProjectD I would like that it pulls the PartA and PartB revision history also so that users cab see the "Revision Graph" of PartA and PartB together using the TortoiseSVN client.

 

I hope I am able to describe the whole scenario to you all.

[Itamar O]

On Fri, Sep 10, 2010 at 12:36 AM, Tech Geek <techge...@gmail.com> wrote:

Geoff,

 

I think I am beginning to undestand what you are suggesting.

 

Right now I am in process of implementing this setup. At this point nothing exits - no ProjectD, no PartA and no PartB. So I will try to summarize what I have undestood so far:

 

1. All our SVN repositories lives under the following location:

\\myserver\SVN_Repositories\ProjectA

\\myserver\SVN_Repositories\ProjectB

\\myserver\SVN_Repositories\ProjectC

 

2. Now each of the Project directories - Project A, Project B and Project C are SVN repositories of their own (TortoiseSVN->Create Repository here)

 

3. Now Mr. ProjectD comes along with has two sub-parts - PartA and PartB.

So I create a new repository ProjectD (TortoiseSVN->Create Repository here) under this (correct?):

\\myserver\SVN_Repositories\ProjectD

and then create two directories (with their own tags, branches and trunk) underneath ProjectD (all using SVN commands) like this:

\\myserver\SVN_Repositories\ProjectD\PartA\trunk

\\myserver\SVN_Repositories\ProjectD\PartA\tags

\\myserver\SVN_Repositories\ProjectD\PartA\branches

\\myserver\SVN_Repositories\ProjectD\PartB\trunk

\\myserver\SVN_Repositories\ProjectD\PartB\tags

\\myserver\SVN_Repositories\ProjectD\PartB\branches

 

Note that Part A and Part B are not their individual repositories. They are just directories that live under ProjectD which is a repository.

so far all good.

 

 

4. Let's say now PartA and PartB code development begings and at some point a tag is created for each of their release:

\\myserver\SVN_Repositories\ProjectD\PartA\tags\REL-1.0

\\myserver\SVN_Repositories\ProjectD\PartB\tags\REL-1.0

 

Now let's say the output of Part A - PartA.xcf and output of Part B - PartB.xcf are concatenated into a file called PartAB-R1.xcf.

 

My questions:

Q1. At this point I would somehow like to store this file (PartAB-R1.xcf) into my SVN repository (ProjectD). What would be an ideal location (logically) to store such a file. Should I be doing any kind of merging from tags (REL1.0) of PartA and PartB to create another node called "Combined-REL-1.0" or something like that. I would like to avoid this if possible.

this is where the ProjectD/Releases I suggested earlier becomes useful.

what I would have done for the 1.0 release:

1. tag the PartA & PartB as you described in step 4,

2. create ProjectD/Releases/REL-1.0 directory,

3. create ProjectD/Releases/REL-1.0/sources directory and set svn:externals on this directory to something like:

  /PartA/tags/REL-1.0 PartA

  /PartB/tags/REL-1.0 PartB

4. create ProjectD/Releases/REL-1.0/binaries directory and import PartA.xcf, PartB.xcf & PartAB-R1.xcf into it

this feels pretty intuitive to me. and it's also a good process to automate (release-management-script).

 

Q2. Also when somebody checks out ProjectD I would like that it pulls the PartA and PartB revision history also so that users cab see the "Revision Graph" of PartA and PartB together using the TortoiseSVN client.

In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg).

In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository.

In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph.

[BRM]

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

[Tech Geek]

>In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg).

Yes. I am aware of that.

 

> In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository.

Yes. True.

 

>In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph.

In this case I have to view the "Revision Graph" individually for PartA and PartB. In fact I just tried creating the setup (not using externals so far) that I described in my last post and I do not get the "Revision Graph" option when I right click on "ProjectD" repository under the TortoiseSVN->Repo-Browser. However I do get the "Revision Graph" option when I right-click on PartA and PartB individually. I would like to see the "Revision Graph" of both the PartA and PartB together so that the one can get an overview of the entire project in just one snapshot. Is this possible?

 

[Tech Geek]

For some reasons this message was returned to me by the mailer daemon. So resending it again.

 

>In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg).

Yes. I am aware of that.
 

> In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository.

Yes. True.

 
>In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph.

In this case I have to view the "Revision Graph" individually for PartA and PartB. In fact I just tried creating the setup (not using externals so far) that I described in my last post and I do not get the "Revision Graph" option when I right click on "ProjectD" repository under the TortoiseSVN->Repo-Browser. However I do get the "Revision Graph" option when I right-click on PartA and PartB individually. I would like to see the "Revision Graph" of both the PartA and PartB together so that the one can get an overview of the entire project in just one snapshot. Is this possible?