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
Received on Thu Aug 10 13:47:00 2006