Hi Julian et al,
Yes, the new 1.7 feature sounds very promising. I was wondering what
WC-NG stands for but I think I get the idea.
I tried sending the rest of this reply earlier and suspect it was
caught in a moderator queue. (( I'm subscribed now; take 2 and
apologies for anyone who has already read this. I suspect that my
.patch files (which I did attach but which did not hit this list)
were stripped because I wasn't subscribed at the time. If the vote
goes positive then I will definitely try attaching them again. ))
I'll tell you the one way in which that might not completely solve
the use-case that I have in mind, and that is doing a series of
partial exports from multiple repositories. Basically I am building
up a server from a series of images that come from different
repositories due to ownership, permission and licensing
limitations. So I might run a series of 10 or 20 exports from
different sections of various repositories, to build up a given
server (e.g. appliance). Using export, there are no conflicts, even
if some of those exports put files into the same target
folders. (Take as a worst-case example, targeting the
c:\windows\system32 folder. )
Would your 1.7 WC-NG feature be okay with a shared .svn folder (e.g.
c:\.svn\ ) with details about exports relating to multiple
repositories? If yes, *great*.
I suspect that non-Windows users would just use yum or equivalent for
my use-case... meanwhile I came up with this process of layering
exports of sections of repositories in order to build up appliances
that are similar in some-but-not-all ways.
For anyone who is feeling +1 about the feature, I'd be interested in
any suggestions for a better name for the flag. The reasoning behind
the verbosity was that people could simultaneously realize the
usefulness (skip large unchanged files) and the danger (what if a
real change did not change the byte size ( bad luck )).
Thank you for your consideration.
- Ann
At 09:34 AM 7/27/2010, Julian Foad wrote:
I'll also note that we are developing in a direction which will probably
help you in the future. It sounds like what you really want is to be
able to "svn update" a tree that doesn't have the ".svn" folders in it.
In v1.7 we will have just one .svn folder, in the root of the versioned
tree, not in every subdirectory. After version 1.7 we may develop an
option to store most of the metadata somewhere else, outside the
versioned tree, so that ".svn" folder becomes very small. That's still
to be thought about, and it would be useful to know whether that would
help you.
Regards,
- Julian
