Hi Marc,
I had an indepth look into this half a year ago.
I was wondering about converting shares. SVN has a mechanism for
handling UNIX symlinks where they attach a particularly phrased
property (attribute?) to the file. This property tells SVN that this
file is actually linked to the other file. UNIX clients doing
checkouts/updates will get a properly formed symlink, but Windows
clients doing the same will receive a copy of the linked file.
Actually svn is handling symlinks as a kind of special command like
files. They use the content of the versioned file and the property to
implement this ability. In the content of the file, there is something
like a shell script that will create the share upon retrieval. The
property only instructs svn to perfom the action in the file.
I have looked into a possibility to perform a similar thing on windows,
but even if this is possible, this involves modifying subversion itself.
You can have a look here to get an idea:
http://svn.collab.net/viewvc/svn/trunk/subversion/include/svn_types.h?revision=18946&view=markup
line 103
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/io.c?revision=19420&view=markup
line 419
(The following is slightly off topic, but I suspect a group of VSS
users interested in SVN is more likely to actually think about this
than a group of pure SVN or CVS users)
We make heavy use of "share" in VSS, and that is the only remaining
sticking point in a move to SVN. The lack of any mechanism for
lightweight reuse in SVN (and CVS before it) has always struck me as
odd. If I've got a simple .h file of useful definitions and inline
functions, I don't really want to have to bring it in as a
subdirectory under my project. Nor do I want to have to go out to the
home project of each subproject to retrieve the newest version, copy
that over into appropriate subdirectories under my project, and the
update just to keep my versions in sync with the originals. I have
been perfectly willing to accept that I was simply missing a usage
model, but vss2svn's inability to transfer over shares suggests that
this is not the case...
I know what you are talking about, but in this case you should really
consider your usage model. You could also use the "svn:exteranls" to
implement something like sharing. I know that starting an infrastructure
sometimes needs time, that you don't have at your hand. But sooner or
later it will sell back the work you put into it.
The most beneficial usage szenario was sharing and pinning for me. With
this method it was easily possible to perform a bugfix in the tip and in
a maintenance version. But the drawbacks of this method start to plaque
me and therefore I'm willing to switch to a new model. So I expect that
I will miss a few merges in the next future until I have found my new
way to keep track of things.
Thanks for the work on vss2svn!
Hope you make use of it.
Dirk
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
