On Wed, 2006-08-09 at 10:14 +0200, Henk Wissink wrote:
> > 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.
That corresponds to copying an existing version to a branch and making
the change there.
> 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.
This is kind of an odd concept for version control, because changing
things high in the tree will affect everything below and leave you
without a way to re-create the old versions. With subversion you'd
need to merge the changes you want everywhere you want them, although
typically you would do ongoing development on the main trunk and
periodically make branches from there to pick up new work.
> >> 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.
Yes, making automatic changes doesn't quite mesh with the idea of
version control. But you can merge changes where you want them.
> 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!
If you want a new branch you can aways make one.
> 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?
Yes, but if you understand the structure you have and the branches you
want to end up with you can probably write a script that will walk
down each branch of your directory tree copying the files into a
checked out working directory and committing each level in sequence.
> > 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.
Which means that you can have changes you can't reproduce and
surprises at the lower directories. In exchange for that you
get the ability to change a lot of things at once without doing
explicit merges or starting a fresh branch from the trunk. You'll
have to decide which is more important.
> >> 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.
This is a mechanism that does let you make a choice about the tradeoff
above. If you peg the external to a version level in the reference
and change it when needed you get reproducible builds. If you pull the
head you'll always get the updates. But you have to move the parts
you want to handle this way to different repositories or at least
locations.
> 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.
The only benefit (really tradeoff...) I see that subversion won't handle
in a better way is the ability to back in changes that affect many
things without explicit merges.
> 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.
I think if you just walk down your directory trees committing to
branches you'll end up with all the same things.
> 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 the future, you'd probably want to commit frequently so the
timestamps
will be accurate either way. I think someone mentioned a way to get
the file timestamps to be used, so that may work if you can preserve
them during the copy into the workspace for the initial repository
build.
> 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.
Version control systems exist to prevent 'transparent' changes. If
you want the change you can merge it - but the mechanism of actually
changing the file is rarely as much of a problem as knowing whether
or not each branch should have it. That will depend on why you
made the branch to differentiate it from the trunk in the first place.
> 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?
Yes, that's what I assumed from your description - that each lower
directory was a subsequent change to the branch above.
> 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.
That often happens with version releases based on time-line updates too.
Not everyone will update every time you make a release, and often you
must do maintenance fixes to old versions.
> 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.
OK, but I'm not sure that matters in terms of repository structure.
You have the same requirements when some people insist on running
something earlier than your last release.
> 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.
Subversion will let you do both.
> 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.
And subversion provides that as well without needing an actual copy
because it is already able to construct any version that has been
in the repository. It will look like a copy, though.
> 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
You'll have to decide whether it is better to use externals to
pull in current common files or do explict merges to propagate
a change where you want it, depending on how important it is to
be able to reproduce old builds exactly. Or perhaps you can
migrate the changes that constitute your version differences
back into the trunk with conditionals that your build system
understands so you don't have to keep the branches separated
for ongoing development.
> and
> - keeping original file date/time stamps
I can see this as an issue in your initial conversion but don't see
why it would matter much after that.
--
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 Wed Aug 9 19:52:03 2006