I consider a revision control system which ships without support for merging
across renames to be "shipping software with premature design elements."
I'm not in the habit of passing judgement on a project's release decisions
unless
I'm voting on the release. Supporting renames in merges seems like a challenge
to me, and I certainly don't feel short-changed as a user for not having that in
the current release.
This comes a bit from background, and a bit from architecture.
"Challenge" in Subversion's architecture, it does seem like. Other
source management systems don't seem to have a problem.
That being said, I will point out that there are a number of people at Apache
who
feel that git is a better subversion client than svn is. That's something that
a better working-copy might be able to address, but who knows (other than Greg)
how extensive the changes required might be.
We can hope. :-)
But, these are "low hanging fruits" from the perspective of a person at
Apache who is provided with a "just change your work instructions to
call GIT instead, and things will become better!" It does not speak to
the value of the future - only to the accessibility of the feature.
For the GCC designers, they were confronted with the question of "why
not use the Eclipse Java compiler that supports Java 1.5 instead of
working on your own that will always be behind?" Subversion could do the
same. If the GIT model is truly better, then the Subversion community
could recommend that GIT be used. There is nothing to say that both
client and server must be part of the same solution. If I look at
XMPP/Jabber, for instance, I see servers and clients that are developed
entirely separately. If GIT works for the Apache folk, what makes you
think that providing a Subversion client that provides *some* of the
capabilities, would really bring these people back into the fold?
That said, there is a lot of potential for a fixed working copy model,
so I'd like to see it completed as well! Performance is the #1 reason
from my perspective.
What about you?
In terms of guilt not being a motivator - what do you suggest *is* an effective
motivator?
Leadership by example. I've never seen an open-source community actually do
anything
based on the quality of someone's rhetoric. Get involved, make commits, change
things.
People will pay attention to your work. IME, open source developers will
typically
ignore arguments. Be happy that someone here blogged about your post, because
more
than most people casting stones typically will get from a dev team.
Quite true. Thanks, Karl. :-)
Karl said that "more bugs = more users = probably good". I challenged this. If
you think I am wrong for challenging this, state your case.
Right/wrong isn't the point. That such discussion is inconsequential to
subversion is.
Hmmm... Even if I agree that my contributions have zero impact on the
actual design (which I honestly do not know - I think I've seen people
listen, but then, maybe they came to the conclusions on their own, and
their responses only confirm that they were already on it?), how the
design community communicates with the user base, and how the user base
feels they are being represented and treated will make influence how
they feel about using the product.
I come away from the discussion with the confidence that at least some
of the designers of Subversion understand and care about what I think.
This lets me have some confidence in presenting Subversion as a
alternative that I can put my name behind. I tell 10 people, who tell 10
other people, ...
Putting up with fools such as myself ( :-) ) will provide value later.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
