On Fri, Dec 30, 2011 at 08:22:50PM -0500, Mark Mielke wrote:
> In any case - this is just yet another example of how Subversion
> really doesn't scale. That it still can't properly merge across
> branches or renames is much more important...
Mark, are you trying to make a useful contribution here on the dev@ list?
The above digression makes you sound more like you were here to complain
about random and very loosely specified aspects you don't like about
Subversion's behaviour. This isn't productive and is not going to fix
any problems.
See http://www.producingoss.com/en/common-pitfalls.html#productive-threads
To fix your svn:author problem, you or someone else in this community
could try to come up with a useful set of conventions for storing extra
information in svn:author or another revision property, and what the syntax
to store such information would look like. Because, as you already pointed
out, your problem is rooted in a lack of conventions, so this is what we'd
need to address. If needed, also specify a way of how Subversion could be
configured by users to optionally enable this new feature so users can reap
the associated benefits. If someone writes a nice spec we can file an
enhancement request in the issue tracker asking for someone to implement it.
But if the spec touches on unrelated aspects (such as merging moves), I'd
suggest to put those in a separate set of suggestions and dev@ threads.
To fix your merging moves problem, you could join the currently on-going
efforts to fix it. In particular we are currently working, and are looking
for help, in these areas:
1) Making muti-layer nested local moves properly (e.g. moves within locally
copied subtrees) -- simpler local move situations are already implemented.
2) Detecting server-side moves -- some prototype code exists but there
are many things left to design, specify, and implement, especially
regarding the means we're going to offer users to solve tree conflicts
involving moves.
While it is always welcome, there is no need to go to the effort of
contributing code. Useful contributions can be made with much less effort.
For instance, it helps a lot if you think about aspects of this (very large)
problem space and try to describe how you'd like Subversion to behave in
use cases which are important to you. Some, but not all, of the current
behaviour design around moves is made without user input. For many use cases
no proper design even exists yet. So more input is definitely welcome.
And *now* is the time to submit your input, before a lot of code has been
written that implements behaviour which may or may not turn out to be
ideal for your situation. Thanks.
Received on 2011-12-31 13:11:20 CET