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<m...@mielke.cc>
