On Fri, Sep 10, 2010 at 12:36 AM, Tech Geek <techgeek12345_at_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.
>
Received on 2010-09-09 23:58:23 CEST