[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1618138 - in /subversion/trunk/subversion: libsvn_fs_fs/caching.c libsvn_fs_fs/fs.c libsvn_fs_fs/fs.h libsvn_fs_fs/fs_fs.c libsvn_fs_fs/fs_fs.h libsvn_fs_fs/hotcopy.c libsvn_fs_fs/structure tests/cmdline/svnadmin_tests.py

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Sun, 17 Aug 2014 03:53:37 +0400

Hi Branko,

> May I ask why you thought it's OK to ignore my request to implement this
> major new FS feature on a branch and committed directly to trunk instead?
> Clearly your change was incomplete, judging by the following several
> commits. This is despite the fact that I plainly told you that this
> community decided a while ago not to develop untested new features on trunk.
> Stefan^2 even created the feature branch for you.

As I see it, this was a suggestion, not a request, and I did not ignore it.
However, the patch received proper attention, we did resolve the technical
issues with it, so I thought there is nothing wrong with committing it.

It looks like we have another misunderstanding here with the "major FS feature"
part. From my point of view, this is a *fix* for an existing FSFS feature
(ability to share data and cache filesystem data), which does not work under
certain circumstances. What I mean is, if this is a "major FS feature", what
would a "minor" feature look like? And what would be a good example of a
major FS feature with the same size, impact and importance for an end user,
that went through the branch and voting procedure?

> Now I'm going to ask you nicely to recreate that branch from current trunk
> and revert this commit and all further related commits from trunk; I believe
> that the full list is:
> 1618138; 1618151; 1618177
> but don't take my word for it. Then, when you're sure the feature is ready,
> ask for a vote to get the branch merged to trunk.
> Thanks,
> -- Brane

If you insist, I will revert these changes from trunk and will attempt to commit
them as a major FS feature with branching and voting. However, I do not really
see any technical reason to do that. This is not a destabilizing change, and
it solves a well-known problem that even we keep stumbling upon during the
development process.

Evgeny Kotkov
Received on 2014-08-17 01:54:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.