On Fri, Sep 10, 2010 at 12:36 AM, Tech Geek <techgeek12...@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. > > I hope I am able to describe the whole scenario to you all. >