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
Received on 2010-07-27 16:59:31 CEST