Les Mikesell 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?
This >>IS<< the version control structure used for many years now. Putting a modified source (let us call it 'commit')
in one of the lowest subdirectory levels includes the change only in that version. Changing a file on a node higher up
in the tree gives the change in all versions descending from that level. Unless of course a version down the line has
its own file with that name/type. If it needs the change too, then its own file must be changed as well.
>> 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.
I know. But that mechanism does not support for automatic propagation of a new change for all related versions. Files in
branches/tags have some history in common but not an automatic common future (page 50 of the book) as I described in my
reaction for point 1 above! That is why I ended my original request with "without loosing (too much) implicit and
explicit relational information". I think that when I start using subversion, I have to port (page 50-52) each and every
change explicitly for all versions that now have a common node in the directory structure and share a single file.
Right?
>> 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.
Correct. In our current set-up that is implemented by 'borrowing' missing files from the directories higher up during
the building process.
>> 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.
I have read the use of externals on page 152 of the svn-book.pdf and I already thought that could take care of the
common part. Thank you for confirming.
>> 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.
Correct. And that 'externals' mechanism will take care to have the common part included for build purposes.
>> 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.
I agree. I certainly see the benefits of subversion. But I am trying to find out whether or not it is possible under
subversion to keep the (implicit) benefits from the current set-up. And if so, how I have to import files, i.e. what
specific properties I might have to account for to loose as less relation-history as possible.
Example: date/time stamps of files seem to be different under subversion anyway (no matter default or by using
"use-commit-times = yes") whereas they are now used as an essential part of the comparison process to find where and
what should be changed. In case a change is implemented in some transparent way (we call it 'compile-time flags'), files
anywhere in the directory tree that were the same before the change can still be kept the same afterwards. That costs
virtually no time whereas maintenance for versions that need that change in the future takes less time: some files
already have the change, it must only be effectively included with some compile-time configuration item from that moment on.
>> 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.
From your description I somehow get the idea that you think that each lower subdirectory level represents a more recent
release of a software version who's initial release can be found in its main directory.
Am I correct?
If this were the case then it would make relationship-things easier.
In my original point 2 I stated that each node represents a software version still in use today. In other words, the
current contents of all trees do not show a time-line of releases but only the up-to-date state of all current versions
used in the field. It is like a collection of inter-related working copies: you can only see the total difference
between two versions, not the order in which the various differences were introduced in the past.
Of course, whenever a release is sent into the field, a kind of 'tag' is archived offline to be able to rebuild it when
needed.
Thank you for your help so far Les.
I feel I do not have all the answers yet to convert my current directory/file structure to a subversion repository
without loosing benefits of the current set-up, if possible at all.
If someone can assure me that things like
- a single-point-of-update for related versions and
- keeping original file date/time stamps
is totally out of the question then it ends here. I either have to live with it or try to find some other control tool
that offers this.
Does anyone else have some feedback?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 9 10:17:28 2006