[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: How can a project be divided up between two repositories?

From: David Weintraub <qazwart_at_gmail.com>
Date: Sun, 18 Oct 2009 00:06:20 -0400

I think I sort of understand this, but let me restate this a bit:

Site A contains:

File_b
File_c
File_d

and a file I'll call File_A[1]

Site B contains:

File_b
File_c
File_d

and a file I'll call File_A[2]

File_A[1] and File_A[2] are site specific derivatives of the same file. For
example, it might be some sort of preference file or a file that contains
custom code. Is this correct?

There is no easy way to do this in Subversion itself. In fact, the only
version control systems I know that somewhat supports something like this
are Perforce and ClearCase. Perforce allows you to specify the working
directory layout in some very unusual ways. One is to overlay the contents
of one directory (say your main site) with a custom directory (say files
that are customized for a particular site). Then, if there is a file
overlap, the file in the customized directory is visible.

ClearCase does something similar except these files live on branches and you
can specify in your view which version of a file to display.

Both, however, add a layer of complexity because now developers must
construct and maintain a view before doing their work. One of the great
advantages of tools like Subversion is simplicity. I simply checkout the
right module without first creating a view.

The best way to do this in Subversion is with your build system. That is you
have a directory structure something like this (using your original
scenario):

Main
   File_b
   File_c
   File_d
           Site
               Site_1
                    File_a
               Site_2
                    File_e

Your build system would take a parameter (whether your building for Site_1
or Site_2) and then build the software with the correct files for that site.

If you need to, you can use a pre-commit hook to specify who can modify what
files.

On Thu, Oct 15, 2009 at 3:43 AM, Tom Lenz <astonishenator_at_gmail.com> wrote:

> Suppose I have two sets of files that I want under version control, Site
> A and Site B, containing files as follows:
>
> Site A:
> File_a
> File_b
> File_c
> File_d
>
> Site B:
> File_e
> File_b
> File_c
> File_d
>
> I want to find a way to specify:
> If a change is made to File_a, it applies only to Site A. Call this Group
> 1.
> If a change is made to File_e, it applies only to Site B. Call this
> Group 2.
> If a change is made to File_b, File_c or File_d, the change gets applied
> to both Site A and Site B. Call this Group 3.
>
> The files have to be in a certain location relative to a directory
> structure. For example, File_a and File_e must be in the same directory.
>
> Also, in some cases, File_a and File_e have the same name.
>
>
> From time to time it may turn out that I want to move a particular file
> from Group 3 to Group 1 or Group 2.
>
> The way we're doing it now is that Site A is in one repository and Site
> B is in another repository, which works and is sort of simple, but it
> has a big disadvantage in that if files in Group 3 get changed, they
> must be manually copied to from one site to another. This is a little
> worse in our case because in reality there are more than two sites
> involved.
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2407801
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408608
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-18 06:07:30 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.