edit and wordpad work for builtin stuff
I have been using FTE ( http://fte.sourceforge.net/ ) for the last several
years... it shows the carriage return character... visual studio, actually
the only one that doesn't behave well is notepad
On 11/22/06, Brian May <[EMAIL PROTECTED]> wrote:
>
> "J" == J Decker writes:
J> On a note from some windows programmer that appreciated the
J> conversions when checking out linux-like sources to have
J> 'notepad' work as a browser; While some days I can agree, in
J> the end, one must make sacrifices and call a goat a goat, and
I have to state a vote.
I had lengthy discussions with CVS on similar topics, and resorted to
hacking my own CVS to work properly, that is, if a text file has \r\n, keep
\r\n, do not convert to \r\r\n.
If a text file has \r or \n in some sequence [\r\n]* this is an end of line,
if \n's exist mult
The logic for determining line endings within reasonable limits is entirely
feasible in practice as well as theory.
On 11/21/06, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote:
I've been thinking about this issue a number of times, and have
discussed it as well.
A thought that came to
On Tuesday 21 November 2006 23:51, Brian May wrote:
> Recently we got a sourceforge project converted from CVS to
> subversion.
>
> The process automatically checked in the files using text mode
> conversions.
>
> The result was that a tar.gz file (yes, having this in the project is
> somewhat weir
On Wed, Nov 22, 2006 at 10:05:13AM +1100, Brian May wrote:
> > "hendrik" == hendrik <[EMAIL PROTECTED]> writes:
>
> hendrik> Just for historical record, this famous Microsoft
> hendrik> "incompatibility" is actually a point in which they
> hendrik> followed the official standard.
On Wed, Nov 22, 2006 at 10:13:08AM +1100, Brian May wrote:
> > "hendrik" == hendrik <[EMAIL PROTECTED]> writes:
>
> hendrik> In monotone, I suggest that a file that has been
> hendrik> character-converted on checkout have its line-end codingw
> hendrik> reverted on checkin, on a l
Larry Hastings <[EMAIL PROTECTED]> writes:
[...]
> I'm not sure what SVN using two separate values (one as a
> mime-type!) buys them.
I believe the theory is that you could use different merging programs
for some types. text/xml is the usual example, where you might have
an XML tree-merging pr
Brian May <[EMAIL PROTECTED]> writes:
>> "Bruce" == Bruce Stephens <[EMAIL PROTECTED]> writes:
>
> Bruce> Sure, that may happen. That's just a bug, though, isn't
> Bruce> it, so you commit a revision containing the changes to that
> Bruce> one file (including attribute change) as
Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:
[...]
> Now, please, before you start reacting, I *know* that the whole file
> isn't stored, only the delta. Unfortunately, I know diddly over
> squat about xdelta, so a question is if storing different EOL
> formats at different times cr
> "hendrik" == hendrik <[EMAIL PROTECTED]> writes:
hendrik> Just for historical record, this famous Microsoft
hendrik> "incompatibility" is actually a point in which they
hendrik> followed the official standard. ASCII was designed
hendrik> without a newline symbol; instead, i
> "Graydon" == Graydon Hoare <[EMAIL PROTECTED]> writes:
Graydon> Woah! Did we really leave it like this? That's
Graydon> terrible. We added an attribute to files called
Graydon> mtn:manual_merge that controls whether the merger
Graydon> believes it can do line-merging on the f
Hi,
I'm newish here, so my opinion might not count for much, but I
think this is one area where subversion got things right. I highly
recommend that people read about subversion's system before making up
their minds. http://svnbook.red-bean.com/nightly/en/
svn.advanced.props.html In pa
On Tue, 2006-11-21 at 10:34 -0500, [EMAIL PROTECTED] wrote:
> By the way, *does* monotone use a line-by-line diff?
> I thought it used a character-by-character diff based on compression
> technology.
It uses a normal line-based diff for merging, and uses xdelta
(character-based diff, sorta) for
Larry Hastings <[EMAIL PROTECTED]> writes:
[...]
> FWIW, I'm a Windows programmer, so I actually /use/ eol convention,
> so if I might chime in with my opinion...
>
> I agree with Nathaniel: eol conversion should be /disabled/ by
> default, and should be /enabled/ with a setting.
> Principle-of-l
> "hendrik" == hendrik <[EMAIL PROTECTED]> writes:
hendrik> In monotone, I suggest that a file that has been
hendrik> character-converted on checkout have its line-end codingw
hendrik> reverted on checkin, on a line-by-line basis. Thus only
hendrik> when the user explicitly e
> "Richard" == Richard Levitte <- VMS Whacker <[EMAIL PROTECTED]>> writes:
Richard> format on extraction. So if something was stored with
Richard> mtn:eol = CR (on a Mac, typically), all CRs would be
I might be mistaken, but I believe this file format is obsolete as of
Mac OS X, now
> "Bruce" == Bruce Stephens <[EMAIL PROTECTED]> writes:
Bruce> Sure, that may happen. That's just a bug, though, isn't
Bruce> it, so you commit a revision containing the changes to that
Bruce> one file (including attribute change) as a child of the
Bruce> original, and merge i
William Uther <[EMAIL PROTECTED]> writes:
> Hi,
> I'm newish here, so my opinion might not count for much, but I
> think this is one area where subversion got things right. I highly
> recommend that people read about subversion's system before making up
> their minds. http://svnbook.red-bean.c
19 matches
Mail list logo
