On Tue, 2006-08-08 at 16:29 +0200, Henk Wissink wrote:
> 1. The current "repository" consists of a number of top level directories,
> each containing a variable number of nested subdirectories with a variable
> depth.
Is there some reason to maintain this layout other than the fact that
you don't currently have version control?
> 2. Each subdirectory level in this structure represents a different
> software version to be maintained.
With a version control system, these would typically be branches with
tags made at release points.
> 3. Each directory level only contains those files in which it differs
> from its parent directory level (note the recursive nature of this!).
> For building purposes these files have precedence over the files with
> the same name/type in higher levelled directories.
Version control systems know what is different in each version (which
is kind of the point...) so you don't have to do this.
> 4. There is a kind of common pool of files.
If they are common only to this group of versions, they can just be
mingled with everything else and merged when you make changes. Or
they can be in their own repository and pulled into the work space
with an 'externals' entry.
> 5. A "working copy" with all files needed to build a version can be
> created by copying all files in the directory tree upward, starting
> at the version's own level and finally that common pool, thereby
> keeping remark 3. in mind.
A 'working copy' in subversion is obtained by checking out the
branch (and perhaps revision) you want. The server knows how to
assemble it.
> In a simple picture it looks like this:
>
> \Common
> \H
> \C
> \...
> \MainTree1
> \Sub11
> \Sub111
> Some files
> \Sub112
> Some (maybe) other files
> ...
> \Sub12
> \Sub121
> Files
> \Sub122
> Other files
> ...
> ...
> \MainTree2
> ...
>
> Maintenance of this directory/file structure has always been taken care
> of by me, being the only one with 'write' rights.
>
> I studied the following document entirely:
> svn-book.pdf
> Version Control with Subversion
> For Subversion 1.3
> (book compiled from Revision 2354)
>
> in an attempt to find clues for an answer to my conversion needs.
> However, I am afraid that by subversion design, benefits (yes there are!)
I think you'll find that subversion provides matching benefits plus
the ability to track changes over time.
> from the current set-up (like the visible relationships between versions
> in the directory/file structure, files with same date/time and contents
> for comparison purposes, which version has the same features and so
> on) will be lost when I simply import all files needed for each version
> (what I called my "working copy" above) into a subversion respository.
I think what you want is to pick the version that has the most common
features among the versions and import that into your trunk. Then
copy that base into branches for each version you maintain, check out
the branch (or 'switch' your working copy to it), copy in the real
version of that branch's files into the workspace and commit them back.
If you want to maintain your old history, you'd start with your top
version subdirectory and do a commit after copying in the changes from
each newer level. If you only want to start with the latest version
in each branch you could just use the latest. Anyway the point is to
get a common version in as the base so all the other changes will be
stored as deltas from that. The files need to have a common ancestor
in the repository to track the changes.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 8 21:06:42 2006