Simon Large wrote:
> Diffs-per-line doesn't sound (on the face of it) too hard to add. Editing
> I'm still sceptical on, not because I don't think its a good thing, just
> that it is hard to do right and a great deal of work which would draw effort
> away from the core of the project.
From my point of view, editing is the easier part. Showing in-line
diffs would be much harder to do. The Subversion diff library doesn't
provide in-line diffs right now. In fact, the "stop" char is hardcoded
to a linefeed, so all diffs are done line-wise. I would have to patch
the diff lib to allow not only line-wise diff but char diff too.
Also, how would one show those inline diffs correctly? In a way that's
intuitive to the user?
But, you can already have _some_ inline diffs right now. If you
configure TMerge to "ingore leading whitespaces", you will get inline
diffs for those whitespaces.
About the editing part: yes, that would be hard to implement too. Not
the actual editing, but the part where I have to make sure that the
files don't get messed up by editing them.
The problem with editing the files is that text files are not "save" per
se, there are just too many codepages/locales/encodings for them! And
even though it is defined that UTF8 files must have a BOM and Unicode
files must have yet another BOM so that editors can identify them, most
editors around completely ignore that - and some of them don't even work
if the BOM's are actually there!!!
Try once the following: fire up your webbrowser, google for "free text
editor" and download at least five of them. Then open UTF8 files in them
and save them again (insert an empty line somewhere to make sure the
file is really written again). Do that with every text editor you have.
Then, compare those saved UTF8 files - you will find that they're
different!
Most text editors out there can't deal correctly with UTF8 files or
UNICODE files, and don't even start trying different codepages with them
- they might work for english and maybe even european codepages, but
once you have a file encoded with a e.g. chinese codepage you _will_
loose your data with those editors.
That's why TMerge doesn't touch the file contents at all. So even if
TMerge doesn't show the chars correctly because it can't find out the
correct codepage/encoding, you still can do a merge and not have your
files messed up!
>>That's also why I would like to see TMerge decoupled from TSVN.
>
> That is a question for Stefan. Apart from new packaging, it would need some
> further checks to make sure it doesn't fall over when used without TProc.
The idea of TMerge was to be independent of TSVN. And it still is. The
only thing you need is the Subversion diff library, but that's not a
problem since that library was written so that other programs can use it
too.
But why should I decouple TMerge from TSVN? I mean as long as no one is
willing to work on it and help out, I would just have more people
complaining about missing features! And even I need some time for myself
once in a while...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Sep 28 13:16:09 2004