You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Henk Wissink <He...@Boschman.NL> on 2006/08/08 14:29:58 UTC
How to convert specially set-up subdir tree into svn
Hello,
I checked the FAQ and this list's archive but could not find an answer. I have the following at hand in a Windows2003
server/WindowsXP environment. Only in case use of subversion would deliver a workable environment, I like to convert the
directory/file structure described below to a subversion repository.
1. The current "repository" consists of a number of top level directories, each containing a variable number of nested
subdirectories with a variable depth.
2. Each subdirectory level in this structure represents a different software version to be maintained.
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.
4. There is a kind of common pool of files.
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.
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!) 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.
Is there anyone that has experience converting such a software maintenance set-up into a subversion repository without
loosing (too much) implicit and explicit relational information?
Best regards,
Henk Wissink
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Les Mikesell <le...@gmail.com>.
On Thu, 2006-08-10 at 13:44 +0200, Henk Wissink wrote:
> Les Mikesell wrote:
> > This is kind of an odd concept for version control, because changing...
>
> I am merely on a search whether or not I can have the best of two:
> implicit information (made explicitly in some way in Subversion)
> from the old tree structure used for 15 years now, and the native
> control features of Subversion.
You can move the implicit information in your tree structure into
subversion by building workspaces that match each node and
committing them. If you do this following your hierarchy you'll
pick up the existing file ancestry/relationships at least in their
current states so you'll be able to do diffs, etc. with sensible
results between versions and be able to reconstruct any point where
you did a commit.
> > 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...
>
> For now that is still weigh beyond my knowledge of/experience with
> Subversion and scripting tools (under Windows). Do you mean software
> like Perl or Python?
I was thinking of unix shell or bash, but if you have a build tool that
assembles a workspace from a node you are most of the way there. Take
what you want to be the baseline version of this workspace and import
that
for your trunk. Then branch it for a version, assemble 'your' version
into the checked out workspace and commit it. You'll have to manually
deal with 'svn add' and 'svn delete' of new and removed files before
committing, but otherwise you just copy the changed files on top of
the last version and commit, doing this for each version you want
to be able to rebuild.
> > 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 am not sure I understand this. It have the idea you see a way of storing
> changes for a certain parent version where a subsequent 'svn update' will
> 'automatically' put those changes in the working copy of a child version?
> If so then it seems to be the solution for one of the things I am
> desperately looking for. Is it asked too much to be a little more specific?
The normal mode of operation is to start with a parent set of files from
the initial import. These can be checked out into a workspace and
incremental changes committed. You can subsequently check out any
revision of the workspace that had ever been committed, and there are
utilities to track and view the changes following revisions of the
same original file. As long as you stay on the trunk or the same
branch,
this parent/child relationship with any earlier version is automatic.
The difference with your version is that you are allowed to change
the parent and have it (sometimes) affect the child later. In
subversion
you can create branches that inherit the existing versioning and make
changes that only remain it that branch. However, if you want these
changes to affect the trunk or other already-existing branches you must
merge the changes into them.
> > 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 these remarks give me a feeling that I did not understand that
> previous paragraph correctly... Do I?
Subversion enforces a strict time-line view of changes. When you create
a new branch you copy an existing versioning history, but subsequent
changes are limited to that branch and what they inherited can't
be changed. If you want to pull in changes you made elsewhere you
must do an explicit merge.
> > I think if you just walk down your directory trees committing to
> > branches you'll end up with all the same things.
>
> And as a result, I can only use explicit merges?
No, the merges would be for future development. If you can
walk down your existing hierarchy committing the corresponding
changes to a workspace to a matching branch you'll capture the
relationships you have. What you will lose is the ability to make
a future change in what is now your upper levels and have it
automatically show up in what you've turned into branches. Subversion
freezes the versioning history so that can't happen. If you
want a change in a branch you have to make it there and commit it
or merge the change explicitly from the trunk or another branch where
it was already committed.
> Internally we call each node in the tree a version. Subsequent deliveries
> of such a version to the customer involved is internally called a release
> (which are NOT its child nodes). So, at any moment in time with ongoing
> changes, each version node only shows how the next release of it will
> look like.
I think I understand it now - but it seems like it would be really
confusing if there are many changed instances of the same file
down any path. You'd always have to be aware of whether you wanted
to affect lower levels and in the cases where each level is different
you'd have to manually add a needed change to each copy. Subversion
won't eliminate the need to know - it just reverses the default so
things don't ever change unless you make them change for each branch.
> There is no way to see how it was at any possible moment in
> the past, simply because there was no need for that.
Often you can learn from past mistakes if you review revision history.
You may find a fix or new feature you are planning to try was
attempted in the past and backed out. If you only have the current
state you lose that kind of information. Things like this become
more important if you have several developers or some turnover.
> Although each delivered release is fully backed should it
> ever be regenerated.
With subversion you can not only regenerate the release points, but
any chunk of code that was ever committed. If you now realize why
a deleted feature didn't work you can revive the old code and add
the fix.
> The only reason for starting to work with parent and child nodes 15
> years ago was the sharing of files: less files to maintain, clear
> relationship between versions, as much as possible features in common
> (files stored as high as possible in the tree), fast overview which
> features were private to versions and so on.
If you started with subversion (or cvs 15 years ago) you would probably
have worked mostly on a single trunk of development with branches
made only for work that for some reason or other could not be
merged into the trunk with build/compile conditionals. You may or
may not want to attempt that in future development so you have
less merging of new work into long-lived branches that may all
need the same updates.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Henk Wissink <He...@Boschman.NL>.
Hello Les,
Les Mikesell wrote:
> This is kind of an odd concept for version control, because changing...
I am merely on a search whether or not I can have the best of two: implicit information (made explicitly in some way in
Subversion) from the old tree structure used for 15 years now, and the native control features of Subversion.
> 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...
For now that is still weigh beyond my knowledge of/experience with Subversion and scripting tools (under Windows). Do
you mean software like Perl or Python?
> 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 am not sure I understand this. It have the idea you see a way of storing changes for a certain parent version where a
subsequent 'svn update' will 'automatically' put those changes in the working copy of a child version? If so then it
seems to be the solution for one of the things I am desperately looking for. Is it asked too much to be a little more
specific?
> 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 these remarks give me a feeling that I did not understand that previous paragraph correctly... Do I?
> I think if you just walk down your directory trees committing to
> branches you'll end up with all the same things.
And as a result, I can only use explicit merges?
> 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 a pitty that English is not my native language. It have a feeling I could not explain clearly enough yet the
(file) relationship between nodes in the tree. Please let me have one more try. Maybe it helps to understand my wishlist
for the use of Subversion better.
Internally we call each node in the tree a version. Subsequent deliveries of such a version to the customer involved is
internally called a release (which are NOT its child nodes). So, at any moment in time with ongoing changes, each
version node only shows how the next release of it will look like. There is no way to see how it was at any possible
moment in the past, simply because there was no need for that. Although each delivered release is fully backed should it
ever be regenerated.
The only reason for starting to work with parent and child nodes 15 years ago was the sharing of files: less files to
maintain, clear relationship between versions, as much as possible features in common (files stored as high as possible
in the tree), fast overview which features were private to versions and so on.
With your remarks and those of Ryan Schmidt and John Allen, I think I can preserve more advantages of the current set-up
as I thought I could when I started this message thread. I hope you will be able and willing to answer my question to
you above.
So far, I thank you all for your excellent (and many times detailed) support until now. It is good to see that
Subversion users help each other.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Les Mikesell <le...@gmail.com>.
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
Re: How to convert specially set-up subdir tree into svn
Posted by Henk Wissink <He...@Boschman.NL>.
Hello Ryan,
Ryan Schmidt wrote:
> These points spring to mind:
> ...
> Some of these may not matter to you. You can search the bug tracker for
> "externals" to see all the issues that are open and see if they matter
> to you.
These items show that I carefully have to set-up the working copy and repository structure. I looked into some of them.
For that, it is disappointing to see that user requests for a modified Subversion behaviour with respect to externals
already go back to 2002. There were probably more important things to do.
Thank you for your help so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 9, 2006, at 15:35, Henk Wissink wrote:
> Is there anyone that uses (many) externals who could warn me up-
> front for some pitfalls?
> Is there something I should certainly not overlook?
These points spring to mind:
1. An external can pull in an entire directory, but it cannot pull in
a single file. You'll have to see if your existing structure
accomodates this limitation. If not, you may have to make many
intermediate directories to let you include via external just the
items you need. This may be inconvenient.
http://subversion.tigris.org/issues/show_bug.cgi?id=937
2. Externals are always specified by absolute URL. So you'll be
encoding your complete repository URL into each external definition.
If you ever decide to change your repository URL, or change the
method of serving the repository, this will be a problem.
http://subversion.tigris.org/issues/show_bug.cgi?id=1336
3. If you're going to use Subversion tags to make snapshots of your
development at certain points of time, note that external definitions
do not get tagged as you might expect. That is to say: Suppose today
your repository is at revision 100 and your main line of development
includes an external definition to some other part of the repository,
and you make a tag of this. In a week you've reached revision 200,
and now you check out the tag to see what your repository was like
before. You'll get the main line of development as it was at revision
100, but the external will pull in the other part of the repository
at the current revision 200, not at revision 100 like it was at the
time.
http://subversion.tigris.org/issues/show_bug.cgi?id=1258
There is a script, svncopy.pl, which you can use to create tags which
correct this limitation.
4. Normally, a successful repository checkout is atomic [1]. That is,
if it takes 20 minutes to check out a working copy, and you start
checking out at 10:00, and someone checks something in at 10:10, then
your checkout which completes at 10:20 will not include that change.
Everything in your working copy will be the way it was in the
repository at 10:00. This is good. However, if there are external
definitions, then each of these are downloaded after the main
checkout, and are atomic as of the time that their checkout was
started. For example, at 10:20, you're done checking out the main
directory structure, and then you start pulling your externals. The
first one will download from the repository the way it looked at
10:20 (not 10:00), the next one maybe at 10:21, etc.
Some of these may not matter to you. You can search the bug tracker
for "externals" to see all the issues that are open and see if they
matter to you.
[1] if it succeeds. If it fails, then it's not atomic; part of your
working copy will be left at the old revision while part of it will
already have been updated to the new one.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Henk Wissink <He...@Boschman.NL>.
Hello John,
John Allen wrote:
> You could of course use a symlink (provided your working on a Unix type system), or svn externals.
Our environment is a Windows 2K3 Server and Windows XP desktop, running Subversion with Apache (https).
After Les Mikesell confirmed the use of externals for the common part, I thought it might be possible to maintain such a
nested structure in the repository and use even more externals referring to parent directories to be used. But in this
way, I might end up with lots of external references. However, if it offers me the advantages of Subversion while
preserving (much of) the current advantages, it is probably worth taking a shot.
Is there anyone that uses (many) externals who could warn me up-front for some pitfalls?
Is there something I should certainly not overlook?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by John Allen <jo...@orbiscom.com>.
On Wed 09 Aug 2006 13:04, Ryan Schmidt wrote:
> On Aug 9, 2006, at 10:14, Henk Wissink wrote:
> >>> 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?
>
> Yes... that's correct...
>
You could of course use a symlink (provided your working on a Unix type
system), or svn externals.
> >>> 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.
>
> If you already have a build system that puts together the correct
> package from sources stored in the manner you've shown us, then I
> don't suppose there's any reason why you can't just keep it exactly
> that way in Subversion. You would have to explain the structure
> clearly to anyone with write access to the repository, but Subversion
> is just a (versioned) filesystem, so you can arrange the data in it
> in any way that makes sense to you. "trunk, branches, tags" is just a
> suggestion that you don't have to follow if it doesn't meet your needs.
>
> > 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.
>
> Right—when you commit or import, Subversion stores the current time,
> not the modification time of each individual file. If you want the
> latter, someone has modified Subversion to do that, but you must
> build it yourself. It's called the "text-time branch":
>
> http://svn.collab.net/repos/svn/branches/meta-data-versioning/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
John Allen, mailto:john.allen@orbiscom.com
Orbiscom Ltd, http://www.orbiscom.com
Block 1,
Blackrock Business Park,
Carysfort Avenue,
Blackrock,
Co. Dublin,
Ireland.
Tel: +353-1-217.8603
Fax: +353-1-294.5119
Mobile: +353-085-1295486
Mandriva Linux release 2006.0 (Official) for i586, kernel 2.6.12-22mdk
13:23:19 up 7 days, 5:08, 2 users, load average: 0.43, 0.62, 0.51
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Henk Wissink <He...@Boschman.NL>.
Hello Ryan, thank you for your response.
Ryan Schmidt wrote:
> On Aug 9, 2006, at 10:14, Henk Wissink wrote:
>
> If you already have a build system that puts together the correct
> package from sources stored in the manner you've shown us, then I don't
> suppose there's any reason why you can't just keep it exactly that way
> in Subversion. You would have to explain the structure clearly to anyone
> with write access to the repository, but Subversion is just a
> (versioned) filesystem, so you can arrange the data in it in any way
> that makes sense to you. "trunk, branches, tags" is just a suggestion
> that you don't have to follow if it doesn't meet your needs.
The reason why I started this message thread was because someone had indeed dumped such a rolled-up collection of files
in a new Subversion repository for a few of our different software versions. Because all of those versions in that
repository now have all files (incorrectly time-stamped) without any information of their origin (former inter-related
versions), that kind of Subversion usage effectively kills some important benefits we had thus far. Therefore I first
try to find out how I can preserve as much as possible information currently present in the tree, explicitly (derivates)
and implicitly (call it 'metadata'). Of course I can try to use (probably) many property settings (invent some of my
own) but that would take quite some time to introduce and maintain I suppose. The more Subversion does automatically in
a carefully selected new repository structure, the more I like it.
> Right—when you commit or import, Subversion stores the current time, not
> the modification time of each individual file. If you want the latter,
> someone has modified Subversion to do that, but you must build it
> yourself. It's called the "text-time branch":
>
> http://svn.collab.net/repos/svn/branches/meta-data-versioning/
That would be an option. Thank you.
The reason why I did not check the Subversion sources myself yet is because we like to use as much as possible standard
software. For that matter, downloading once in a while the most recent standard Subversion has solved our needs so far
for some other projects that have been stored.
This answer of you brings me a little closer to my goal.
But there is still the wish to save as much as possible relation-ship information.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 9, 2006, at 10:14, Henk Wissink wrote:
>>> 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?
Yes... that's correct...
>>> 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.
If you already have a build system that puts together the correct
package from sources stored in the manner you've shown us, then I
don't suppose there's any reason why you can't just keep it exactly
that way in Subversion. You would have to explain the structure
clearly to anyone with write access to the repository, but Subversion
is just a (versioned) filesystem, so you can arrange the data in it
in any way that makes sense to you. "trunk, branches, tags" is just a
suggestion that you don't have to follow if it doesn't meet your needs.
> 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.
Right—when you commit or import, Subversion stores the current time,
not the modification time of each individual file. If you want the
latter, someone has modified Subversion to do that, but you must
build it yourself. It's called the "text-time branch":
http://svn.collab.net/repos/svn/branches/meta-data-versioning/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to convert specially set-up subdir tree into svn
Posted by Henk Wissink <He...@Boschman.NL>.
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
Re: How to convert specially set-up subdir tree into svn
Posted by Les Mikesell <le...@gmail.com>.
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