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

Re: Re: [PATCH] Allow clients to check out special files with unknown type

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-02-16 11:38:33 CET

On Fri, Feb 16, 2007 at 11:27:01AM +0100, Peter Lundblad wrote:
> Malcolm Rowe writes:
> > So, uh, is the behaviour described in the first para above correct? (and
> > so I should mark merge_tests 8 as fixed too), or should we actually be
> > testing for a particular behaviour (the current test just checks that
> > there's no error coming out of the merge, not that the merge does
> > anything in particular).
>
> Sounds like an incomplete test to me;)

Yup, but I can't extend it without knowing the intended behaviour :-)

> > I'm leaning towards "this is weird, but probably correct behaviour". I
> > can't think of anything more reasonable that we should do, anyway :-)
> >
> I'd say that the current behaviour is more correct.

The current behaviour of throwing up an error is more correct?

> Maybe a more convenient behaviour for the user would be for all three conflict
> files to be symlinks. letting the user just resolve the conflict by copying
> one of them over the working file. But I don't know how hard that'd be.
>
> Running the merge algorithm on those one-liner files with svn:special doesn't
> seem right either. What about just declaring a conflict if the contents
> differ and do the required detranslations. The working file could
> perhaps contain a more instructive message then.
>

I think you're missing something: the 'left' and 'right' files in the
merge are regular files with no svn:special set. We're merging a change
to a regular file into a special file, that's why I'm having trouble
working out what the right behaviour should be!

Regards,
Malcolm

  • application/pgp-signature attachment: stored
Received on Fri Feb 16 11:38:52 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.