On Oct 5, 2007, at 3:14 PM, Daniel L. Rall wrote:
> On Fri, 05 Oct 2007, Jack Repenning wrote:
>> On Oct 5, 2007, at 2:56 PM, Daniel L. Rall wrote:
>>> However, enforcing a minimum client version isn't an unreasonable
>>> 1.4 clients won't set mergeinfo for merge/copy/move operations,
>>> that merge history will be lost (unless subsequently manually
>>> using 'svn propedit', something which I'd strongly recommend that
>>> average user should not do, given our complex inheritance rules).
>>> You won't
>>> be any worse off than you were with 1.4, but it's annoying none the
>> I think you will be very much worse off, because you will be
>> conditioned to suppose that the merge info is there, yet it is not.
> This is a pretty big assumption for a user who's mixing 1.5 and < 1.5
> tool chains. :-p
It's not about assumptions, it's about confusion. If the tools mix
behavior like this, and bearing in mind that Subversion has become a
richly embedded component, so we're talking about a mix of many
tools, not merely consciously variant versions of one, then the user
has no choice but to make up their own understanding of the models.
That, not to put too fine a point on it, is an appalling crock.
Users do not have access to the finely nuanced history of this mail
list, nor the energy to think these things through.
While I'm sympathetic to those developers who want to mix versions,
or find they must mix versions for various reasons, that can't be the
primary model: common things should be simple, and now that
Subversion has actual users in number far beyond its developers, the
common things have become the user things.
Uncommon things should, of course, remain possible, such as there
being some way to mix versions if you really have to. "Possible when
not simple" might mean "--force" options or such.
Chief Technology Officer
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
Received on Sat Oct 6 00:36:17 2007