You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by sv...@href.com on 2010/07/26 03:04:02 UTC
[PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
[[[
Contributed Feature: enable lazy sync via new export flag,
--skipfilesmatchingsize
* subversion/libsvn_client/export.c
* subversion/svn/cl.h
* subversion/svn/export-cmd.c
* subversion/svn/main.c
Summary: This feature is meant to provide an extremely easy, 80%
effective way for
Windows users to avoid using rsync when they want to export files
repeatedly from a
subversion repository. Although many experienced svn users are happy
using rsync,
Ann believes that enough Windows users would benefit from this
feature, and that it
makes sense to add --skipfilesmatchingsize as a flag.
Discussed in part here: http://svn.haxx.se/users/archive-2010-07/0282.shtml
Patch by: Paul Breen <gr...@yahoo.com>
Suggested by: Ann Lynnworth <sv...@href.com>
]]]
The attached files are patches against subversion 1.6.12.
We modified one further file which you probably do NOT need
( * subversion/libsvn_subr/opt.c ). Our change modifies the output
of the svn --version command
to say that this version is modified from the Collabnet version. In
case you want to see that
for some reason, it is
here: http://greenbreen.com/svn_mod_source/libsvn_subr/opt.c.patch
This is Paul's first patch to svn and Ann's first attempt at
contributing. We tried to follow
all the rules and hope that, if for some reason, this patch is
unusable, you let us know how
to improve it. Please copy me off-list because I am not subscribed
to the dev list.
Thank you for your consideration.
Ann
Re: [PATCH] new feature, lazy sync via export --skipfilesmatchingsize
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Ann,
Patch has not reached the list.
Did you forget attach it?
With regards
Kamesh Jayachandran
On 07/26/2010 08:34 AM, svnusertemp@href.com wrote:
> [[[
> Contributed Feature: enable lazy sync via new export flag,
> --skipfilesmatchingsize
>
> * subversion/libsvn_client/export.c
> * subversion/svn/cl.h
> * subversion/svn/export-cmd.c
> * subversion/svn/main.c
>
> Summary: This feature is meant to provide an extremely easy, 80%
> effective way for
> Windows users to avoid using rsync when they want to export files
> repeatedly from a
> subversion repository. Although many experienced svn users are happy
> using rsync,
> Ann believes that enough Windows users would benefit from this
> feature, and that it
> makes sense to add --skipfilesmatchingsize as a flag.
>
> Discussed in part here:
> http://svn.haxx.se/users/archive-2010-07/0282.shtml
>
> Patch by: Paul Breen <gr...@yahoo.com>
> Suggested by: Ann Lynnworth <sv...@href.com>
>
> ]]]
>
> The attached files are patches against subversion 1.6.12.
>
> We modified one further file which you probably do NOT need
> ( * subversion/libsvn_subr/opt.c ). Our change modifies the output of
> the svn --version command
> to say that this version is modified from the Collabnet version. In
> case you want to see that
> for some reason, it is here:
> http://greenbreen.com/svn_mod_source/libsvn_subr/opt.c.patch
>
> This is Paul's first patch to svn and Ann's first attempt at
> contributing. We tried to follow
> all the rules and hope that, if for some reason, this patch is
> unusable, you let us know how
> to improve it. Please copy me off-list because I am not subscribed to
> the dev list.
>
> Thank you for your consideration.
>
> Ann
>
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by sv...@href.com.
Thanks for the explanation about attachments on this list, Julian. I
tried to find a way to tell Windows 7 to treat the .patch files more
as .txt .... no luck yet. I use Eudora as my email client and the OS
is Windows 7. If I rename the files to *.patch.txt, then they might
go through differently.
Meanwhile for anyone interested, the actual patch files are available
online at the following address, along with a Windows installer for
the compiled binary of the svn client including the
patch/feature. That should make it easy for people to test it (on
Windows) and then comment more meaningfully on the usefulness. I'm
fairly convinced the feature is not needed on Linux.
http://www.href.com/pub/sw/subversion/
I am planning to leave those files online until it is clear whether
v1.7 with Working Copy Next Generation "WCNG" makes the whole issue
moot. Looking forward to testing that further down the track.
Sorry for the delay in reply, and many thanks to all the developers
on this list for your work on subversion.
-Ann
At 04:22 PM 7/27/2010, Julian Foad wrote:
>This mailing list strips patches that have certain MIME types including
>"application/octet-stream" so I suspect that's what happened - it's not
>related to being subscribed.
>
>- Julian
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by Julian Foad <ju...@wandisco.com>.
Re. patches being stripped from the mail:
svnusertemp@href.com wrote:
> 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. ))
This mailing list strips patches that have certain MIME types including
"application/octet-stream" so I suspect that's what happened - it's not
related to being subscribed.
- Julian
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by Julian Foad <ju...@wandisco.com>.
svnusertemp@href.com wrote:
> 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'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*.
No, I don't expect it will cope with that exact scenario. WC-NG is
being designed toward having the ability to manage different parts of
the WC coming from different repositories, but that ability is not
likely to be functional at first and it will not allow the different
parts to overlap in the way you are doing.
- Julian
RE: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by Bob Archer <Bo...@amsi.com>.
> Yes, the new 1.7 feature sounds very promising. I was wondering
> what
> WC-NG stands for but I think I get the idea.
Working Copy Next Generation
BOb
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by sv...@href.com.
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
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by Julian Foad <ju...@wandisco.com>.
I agree with everything Stefan says here: I think it's not appropriate
to include this particular feature, but thank you for offering your work
back to the community and hope that you will keep on doing so.
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
On Mon, 2010-07-26 at 13:28 +0200, Stefan Sperling wrote:
> On Mon, Jul 26, 2010 at 03:04:02AM +0000, svnusertemp@href.com wrote:
> > [[[
> > Contributed Feature: enable lazy sync via new export flag,
> > --skipfilesmatchingsize
>
> > Discussed in part here: http://svn.haxx.se/users/archive-2010-07/0282.shtml
>
> Hi Ann,
>
> As I've said before in the discussion you've linked to, I still think
> using rsync is a better solution to this problem, and I'll object
> adding the proposed feature to Subversion.
>
> Adding an option flag that is too specific is not a good thing.
> The general problem you're trying to solve is making Subversion omit
> certain files from an export, based on a set of criteria. Your set of
> criteria may be file size, the next person's criteria maybe whether the
> file contains source code or image data, or whatever. Each feature in
> Subversion's feature set should be general enough to be useful to many
> of its users. And it should provide added value over existing solutions,
> and I don't see how, in general, the proposed feature adds value over
> using rsync.
>
> > We tried to follow all the rules and hope that, if for some reason,
> > this patch is unusable, you let us know how to improve it.
>
> There is nothing wrong with the way you're approaching us about this,
> or with any rules not being followed. You're doing absolutely fine
> in that regard.
>
> But I think that the feature as proposed simply does not fit into the vision
> the community has for the software. And that is, besides following patch
> submission guide lines, a very, very important part in getting a feature
> submission accepted. I may be wrong, and if the majority of people here
> want to include the feature, fair enough. But I don't expect this to be
> the case.
>
> Please don't feel put off by this, and keep making contributions.
> Contributions keep the project alive and are always valuable,
> even if they do not end up in the actual product. Even as a Subversion
> developer, I also have made contributions that have not been accepted
> or which I had to revert after community discussion following a commit
> I had made. That is simply part of open source development. One such case
> happened just last week, where another developer convinced me that a
> feature I had added didn't add any value. See this discussion for details:
> http://svn.haxx.se/dev/archive-2010-07/0429.shtml
>
> Stefan
Re: [PATCH] new feature, lazy sync via export
--skipfilesmatchingsize
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jul 26, 2010 at 03:04:02AM +0000, svnusertemp@href.com wrote:
> [[[
> Contributed Feature: enable lazy sync via new export flag,
> --skipfilesmatchingsize
> Discussed in part here: http://svn.haxx.se/users/archive-2010-07/0282.shtml
Hi Ann,
As I've said before in the discussion you've linked to, I still think
using rsync is a better solution to this problem, and I'll object
adding the proposed feature to Subversion.
Adding an option flag that is too specific is not a good thing.
The general problem you're trying to solve is making Subversion omit
certain files from an export, based on a set of criteria. Your set of
criteria may be file size, the next person's criteria maybe whether the
file contains source code or image data, or whatever. Each feature in
Subversion's feature set should be general enough to be useful to many
of its users. And it should provide added value over existing solutions,
and I don't see how, in general, the proposed feature adds value over
using rsync.
> We tried to follow all the rules and hope that, if for some reason,
> this patch is unusable, you let us know how to improve it.
There is nothing wrong with the way you're approaching us about this,
or with any rules not being followed. You're doing absolutely fine
in that regard.
But I think that the feature as proposed simply does not fit into the vision
the community has for the software. And that is, besides following patch
submission guide lines, a very, very important part in getting a feature
submission accepted. I may be wrong, and if the majority of people here
want to include the feature, fair enough. But I don't expect this to be
the case.
Please don't feel put off by this, and keep making contributions.
Contributions keep the project alive and are always valuable,
even if they do not end up in the actual product. Even as a Subversion
developer, I also have made contributions that have not been accepted
or which I had to revert after community discussion following a commit
I had made. That is simply part of open source development. One such case
happened just last week, where another developer convinced me that a
feature I had added didn't add any value. See this discussion for details:
http://svn.haxx.se/dev/archive-2010-07/0429.shtml
Stefan