[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix merging with broken softlink as target

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 16 May 2008 09:10:38 -0700

On Thu, May 8, 2008 at 12:47 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
> On Thu, May 8, 2008 at 9:03 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> "David O'Shea" <david.oshea_at_s3group.com> writes:
>>
>> > Ok, this is interesting. I've been looking at merge test 41 for a
>> > while and the difference with the patch applied is that a merge of a
>> > propset eol-style change into the working copy applies the propset but
>> > does not rework the line endings in the local file until committed.
>> >
>> > Without the patch applied, the line endings of the file in the wc get
>> > updated immediately as part of the merge.
>> >
>> > However, the first situation (where the patch is applied) means that
>> > merging the propset now has the same effect as manually doing the
>> > propset (i.e. manually doing svn ps eol-style does not change the line
>> > endings in the local file until you commit).
>> >
>> > So, my question is this... is the fact that the line endings were
>> > changed as part of the merge of a propset, but not by a manual propset
>> > a bug that this patch (inadvertently) fixes or was that difference a
>> > deliberate decision?
>>
>> Hmm, that's interesting.
>>
>> Yes, it looks like an inconsistency on the surface, but I'm not sure
>> it's inconsistent when considered deeply...
>>
>> When you receive a propset of svn:eol-style from the repository, you're
>> also receiving whatever effect that propset had on the file it was
>> committed on. That is, in the merge-from-repos case, the commit has
>> already taken place, so it's natural that the line endings would change,
>> along with the property, on the receiver's side.
>>
>> IOW, receiving the propset via update/merge is not quite the same as
>> doing the propset manually in your working copy. One represents a
>> commit that actually *has* taken place, the other represents an intent
>> to commit.
>>
>> So I think the current behavior should be preserved.
>
> So do I :-) It took me a few weeks before I figured out what the right
> merge behaviour given an svn:eol-style property change, minimizing at
> the same time the number of eol-translations. This is a change way
> past 1.0 though. Can't remember exactly when ...

And in fact this stuff is pretty subtle... I just fixed a bug in it
recently (r30756).

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-16 18:10:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.