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_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
>
> 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
Received on 2010-07-27 11:35:39 CEST