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
Received on Thu Aug 10 18:11:04 2006