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

Re: Repository Structure Question

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Fri, 03 Jan 2014 19:08:01 -0500

On 1/2/2014 5:25 PM, Mike Fochtman wrote:
> Currently the team hasn't used any form of version control on these
> applications because 'it would be too hard...'

I think you can get 99% of the way there by making sure that application
'A' is under full version control. Some version control is better then
no version control, so tackle project A first.

> I'm part of a small development team (currently 4). We have two
> applications used in-house that consist of about 1900 source files.
> The two applications share about 1880 of the files in common, and
> there are only about 20 different between them.
>
> For a lot of complicated reasons I won't go into here, we can't split
> the common files into a shared-library sort of project.
>
> Most of our development goes on in application 'A'. Currently we
> then transferred over to the other application 'B' development
> machine manually and build/test that one.

I would put application B into the same repository under a 2nd root
directory. The primary reason that I recommend a single repository for
both applications is so that SVN 1.8's duplicate detection will keep
your repository size under control. So you would have:

/projectA/(trunk|branches|tags)
/projectB/(trunk|branches|tags)

There's a few ways to tackle moving stuff from project A to project B.

Most of them involve making sure that the "unique" files not shared
across the applications are in a separate directory.

One method would be to checkout project B's files, then use "svn export"
to overlay project A's files into the project B's working copy. It's
messy, but it duplicates your existing process.

http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html

Another option would be to branch A's trunk (or stable release tag) into
B's trunk. Then apply B's changes to make the application look like B.

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html

Or you could combine the approaches and setup your repository like:

/Common/(trunk|branches|tags)
/projectA/(trunk|branches|tags)
/projectB/(trunk|branches|tags)
/buildA/(trunk|branches|tags)
/buildB/(trunk|branches|tags)

Where the files unique to ProjectA are in /projectA/trunk, the files
unique to project B are in /projectB/trunk. The files common to both
applications are in /Common/trunk.

The /buildA/trunk tree is then where you use svn:external to weld files
from Common + ProjectA together into something that builds for
application A. And /buildB/trunk is where you use svn:external to weld
together the application B build.

http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
Received on 2014-01-04 01:08:42 CET

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.