> On Tue, 14 Dec 2004 13:13:04 +0100 (CET), Nicklas Norling
> <email@example.com> wrote:
>> In my best efforts of testing I today created a file with mime-type
>> application/octet-stream (binary that is) to see how it behaved when I
>> created a conflict.
>> The file in question is called Fndbas.cat and exists in r1 and then I
>> a new r2 revision and a conflicting change in my other WC where I run
>> update. I get a warning about the conflict. In the folder I have three
>> files, Fndbas.cat with a conflict marker on it, Fndbas.cat.r1 and
>> Fndbas.cat.r2. What do I need those for? If there is a conflict between
>> file and what's in svn isn't it enough with my file and .r2?
> One file is your original file before you modified it in your working copy
> One file is the file from the repository
> One file is the with the conflict overlay which is your modified file.
>> I use TSVN 'Edit Conflicts' on Fndbas.cat and after a bit of loading I
>> up with two windows; the left containing Fndbas.cat.r1, the right
>> containing r2.
>> On the left I can only select 'Use this text' and on the right the only
>> options are to select 'Use other text'. Is this the way it's supposed to
> Well, that depends. You marked the files as binary, so Subversion only
> 'created' three conflicting files (see above). If you had set a text
> mimetype, then Subversion would have created four files. And those
> four files is what TMerge needs for a three way merge.
I think you missed my point here. I'm not seeing my changes. I'm seeing
the 'original from before I modified my wc' and the version from the repo.
Not a singel bit of my changes are displayed. Also I'm only allowed to
select code from the 'original from before I modified my wc'. Isn't this
just a very complicatied way of doing revert?
>> As a variation I would have accepted a dialog telling that the files are
>> marked as binary and should not be merged using the merge tool, but if I
>> insist... I can do it anyway (for those text-based 'unmergable' files).
> TMerge doesn't check the Subversioin mime-types. It only tries to read
> the files as text and if that fails assumes they're binary.
Maybe it should take mime-type application/* into account? It would be
consistent with e.g. 'Show Differences as Unified diff' (from Log message
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
At the very least it should allow me to diff what's in the repo with what
I've edited, don't you think?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 14 13:36:31 2004