It is also worth pointing out that your response, Stefan, is very will
written and reasonable and I'm putting it on my "to think about" pile.
Thank you.
On 12/31/2011 07:10 AM, Stefan Sperling wrote:
> 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.
--
Mark Mielke<mark_at_mielke.cc>
Received on 2011-12-31 19:45:24 CET