Hi Stefan:
You are correct. I've let my frustration get to me ... after years and
years of waiting and trying to contribute. I agree that the route
forward you describe is the best approach to getting something achieved.
However, I do think it is worth pointing out - very briefly and with
purpose - that there are some aspects that I have seen on this list
which clearly show that the developers of Subversion primarily work from
a simpler requirement set than the developers of other systems, and this
can be quite frustrating to deal with. Things that are clear to others -
such as proper merging across branches and specifically across renames,
so-called "merge tracking", are core functions in other systems but are
bolted on after thoughts in Subversion.
The "svn:author" issue is yet another example of the same. Other systems
have as a core feature a "structured" author value. Unique id portion
plus display portion at least. Subversion chose to leave it as a free
text field which has traditionally only included the unique id portion.
"Good enough" for small teams. Progressively worse the larger the team.
I agree it's not worth ranting. It isn't productive. Part of what I say
is a rant. Part of what I say, though, is hope that by explaining the
problems a bit more, the people who do contribute more can take these
requirements into account during the requirements analysis phase instead
of after the fact as a bug report, and get it right the first time.
Personally, I'm undecided. I joined the list years ago because I
intended to contribute. The philosophical differences have been hard,
though, and I've had trouble justifying to myself that if I were to
spend 40 hours on Subversion development today, that it would be a
worthwhile investment on my part. Honestly, I'm having real trouble
explaining why I would purposefully stay with Subversion when I have
options that do not have these problems that could also benefit from
investment, or might not even require investment as they acknowledged
the problems in their design and addressed it first and foremost rather
than as an after thought.
Pretty negative. Sorry. On the positive side - I've also seen a few of
you really try to attack the hard design problems. Subversion 1.5, 1.6,
and 1.7 are pretty major steps forwards. They're just not as major as
was hoped. :-) Up hill battle all the way. That's really difficult to
consider rewarding. :-)
Sorry all for the interruption.
mark
On 12/31/2011 07:10 AM, Stefan Sperling wrote:
> 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.
--
Mark Mielke<mark_at_mielke.cc>
Received on 2011-12-31 19:25:07 CET