I do hear you. I also question whether RSync, or something, is truly
a good option for Windows users for pulling files from a
repository. Do you know Windows users that use RSync happily? I
fully appreciate that Linux users are happy with RSync. I tried to
find the 2nd product which was suggested on the user list, RoboSync,
as a better option for Windows users, and it seems to have fallen off
the map of realistic options. I could not find a home page or recent
release of it. Do you know how many people use the client side of
SVN on Windows versus Linux or Mac? Is the Windows user base really
small? Or is it more an svn dev policy never to add a feature that
isn't really cross-platform. I guess I could accept that as a basis
for your decision, that makes some sense. Obviously thinking out loud here.
I wasn't sure how many decision makers would vote on this patch, and
whether the responses on the users list were indicative of a final
decision. Is everyone against this?
In any case, no worries, I'm nowhere near giving up on subversion nor
open source. It was wonderful to be able to make a version that
implemented my idea, and I actually hope to figure out how to
maintain it as a fork at least for a while. I thought I could offer
the binary for windows users, and count downloads, and gauge the
interest that way.
I am very happy that the submission was correct in technical
terms. I do appreciate that confirmation & hope you have time to
reply one more time.
Last clarification: the advantage over rsync is that you don't have
to install or learn rsync.
At 11:28 AM 7/26/2010, you wrote:
>On Mon, Jul 26, 2010 at 03:04:02AM +0000, svnusertemp_at_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
>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
> > 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
>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:
Received on 2010-07-26 16:13:35 CEST