(Brief introduction)
I'm a long time CVS guy who has been eagerly watching subversion and has
just started switching 10 years of accumulated "stuff" from CVS to
subversion. I'm also a long time multi-platform developer.
Jonathan Abbey wrote:
>| But for clients, I just pull in the routines I use; I don't want to hand them my
>| whole library. Since it's different files for different clients, I keep
>| copying things around. And sometimes I'll add to the library functions that a
>| particular project is using. Then I have to update all the other projects (base
>| library plus any other projects using affected modules). PITA...
>
>So what would be the desired semantics? You'd want a file in one
>subversion revision subdirectory to be 'hard linked' to a file in
>another, such that it always is at HEAD? I assume that's what you
>have to mean, else you could just use svn cp (or the GUI equivalent)
>to make a zero-cost copy in the repository.
>
>
Try these semantics:
I would like a many to one mapping between paths and versioned objects
(files). Right now it appears that a versioned object, represented by a
wave-front of changes, exists at only one path name with the name
space. Copies can be made, but that links the wave of changes at a
specific point.
I would like to be able to link an additional path to the same
"wave-front" of changes.
e.g.
"svn ln $SVNROOT/some/path/file $SVNROOT/another/path/file"
Now changes to one will be propigated to the other, because they're both
tracking the same wave front. None-the-less, a "svn cp" to create a tag
or "co -r" would correctly specify the state of the repository as it was
at *that exact* time, unlike svn:externals.
Kevin Brannen mentioned a problem with "tagging", and knowing CVS I can
understand his concern. I don't think it would be an issue with
subversion, though, as tags are created by copying.
If someone attempts to check in both paths to this file in one
transaction and they have both been changed an error should be reported.
The nasty thorn I can see is what semantics to apply when both files are
under a path copied with "svn cp". Should they now both be links to the
same wave-front that has ancestry at the point of copy? I think that is
the desired behavior, but what if the two "svn cp" commands are issued
in different transactions? I don't have a good idea of how to deal with
that one, particularly since subversion "branches" are more of a usage
pattern than a hard and fast methodology.
>In a UNIX environment you could just add a rule to zero-cost copy the
>HEAD file(s) into your working environment at build time, couldn't
>you?
>
Perhaps, but from my perspective anything that isn't supported across
all platforms isn't a feature (because I can't count on it being
there). Those people who use subversion only on Unix will probably have
a different view.
> You wouldn't want to lose the ability to check out/export a
>given build in the state that it was in when you did validation, would
>you? I'd hate to create a Subversion checkpoint for my software and
>then go back a couple of years later and have some files not be as
>they were when I built and tested the checkpoint..
>
>
I completely agree. First priority is "don't loose data". Second
priority is "everything is repeatable".
--
Dewey Sasser
dewey@sasser.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 19 00:03:18 2004