Loading ...
Sorry, an error occurred while loading the content.

Re: CVS under Windows trashes sandbox checked out under Unix

Expand Messages
  • John Harvey
    Resent-Date: Tue, 30 Jun 1998 09:59:51 -0400 Date: Tue, 30 Jun 1998 08:30:34 -0500 From: D.J. Miller II Reply-to: jamesm@bga.com
    Message 1 of 10 , Jun 30, 1998
    View Source
    • 0 Attachment
      Resent-Date: Tue, 30 Jun 1998 09:59:51 -0400
      Date: Tue, 30 Jun 1998 08:30:34 -0500
      From: "D.J. Miller II" <jamesm@...>
      Reply-to: jamesm@...
      Resent-From: info-cvs@...
      X-Mailing-List: <info-cvs@...> archive/latest/3387
      X-Loop: info-cvs@...
      Precedence: list
      Resent-Sender: info-cvs-request@...

      Jim Kingdon <kingdonc@...> wrote:
      > > 1. Am I alone in thinking that the CR-LF conversion performed by
      > > Windows CVS is a Bad Idea (tm), or at least something that I
      > > should be able to disable globally?
      >
      > You're not the first to suggest it. But no one has been motivated
      > enough to implement such an option, as far as I know.

      I would, IF I had some time on my hands (heh).

      I briefly looked at this a couple of years back and couldn't find a
      clean, obvious place to turn off the LF<->CRLF translation; it appears
      to be done implicitly by MS library/system calls invoked with "text
      mode" flags in fopen(), etc. I personally find this hard-coded
      translation a real pain in the gluteus maximi.
      ____________________________________________________________

      James Miller in Austin, Texas

      Internet: jamesm@... (198.3.118.20)
      alternate: jamesm@... (198.3.118.3)

      ____________________________________________________________

      Given the above then all that should be needed is to add a binary flag
      to the open. Presumably you would only want to do this on checkout and
      on checkin then remove any CR-LF combinations that had been added by
      some broken windows editor!

      John




      --
      John Harvey
      Division Limited Tel: +44 (0)1454 615554
      19 Apex Court, Fax: +44 (0)1454 615532
      Woodlands Email: john@...
      Bristol BS12 4JT, UK
    • Dick Balaska
      Also sprach Jim Kingdon --- 08:12 AM 6/30/98 -0400 ... I like it just the way it is! I use only client/server though, for consistency sake. I even use
      Message 2 of 10 , Jun 30, 1998
      View Source
      • 0 Attachment
        Also sprach Jim Kingdon --- 08:12 AM 6/30/98 -0400
        >> 1. Am I alone in thinking that the CR-LF conversion performed by
        >> Windows CVS is a Bad Idea (tm), or at least something that I
        >> should be able to disable globally?
        >
        >You're not the first to suggest it. But no one has been motivated
        >enough to implement such an option, as far as I know.

        I like it just the way it is!

        I use only client/server though, for consistency sake.
        I even use client/server from/to the same box. I think of cvs as a c/s tool
        and any other use is shortcutting and short circuiting.

        *Especially* if you are trying to use samba or nfs to read/write ASCII text files.

        The only gotcha i've had to deal with is:
        Visual C++ needs to have CRLF makefiles; since the XPilot source is spit
        out from an HPUX workspace, i tag *.mak, *.rc as binary files so that the HP will
        fetch them as CRLF types.


        _,--"
        `-._ ________-_______ "----
        _----'--'--------------------------------'--'----_
        //_| | \ Dick Balaska / | | _\\
        (_____|_|__= Waterbury CT +1.203.757.6994 =__|_|_____)
        _\_____=___ http://www.buckosoft.com/ ___=_____/_
        \/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
        Windows 98: Just say why?
      • Mark Harrison
        ... I think this is one of the great features of CVS. I maintain some software (the text/code for Effective Tcl/Tk Programming ) that has both unix (.tar.gz)
        Message 3 of 10 , Jul 1, 1998
        View Source
        • 0 Attachment
          James Rauser <rausejme@...> wrote:
          >
          > 1. Am I alone in thinking that the CR-LF conversion performed by
          > Windows CVS is a Bad Idea (tm), or at least something that I
          > should be able to disable globally? It causes us nothing but
          > trouble, and all the tools we use under Windows can handle
          > textfiles with bare line feeds just fine.


          I think this is one of the great features of CVS. I maintain some
          software (the text/code for "Effective Tcl/Tk Programming") that
          has both unix (.tar.gz) and windows (.zip) distributions. It is
          so easy with CVS: On unix: "cvs export, tar cvf ...", and on
          windows: "cvs export, zip ..."

          And everything works perfectly. Client/server CVS is truly wonderful.

          Just mho,
          Mark.

          markh@...
          Mark Harrison, AsiaInfo Computer Networks,
          Beijing, China
        • Mike Pumford
          ... I tried this once. It caused more problems than it solved. I came to the conclusion that allowing the OS to do the CRLF translation was the only rational
          Message 4 of 10 , Jul 1, 1998
          View Source
          • 0 Attachment
            John Harvey wrote:
            >
            > Given the above then all that should be needed is to add a binary flag
            > to the open. Presumably you would only want to do this on checkout and
            > on checkin then remove any CR-LF combinations that had been added by
            > some broken windows editor!
            >
            I tried this once. It caused more problems than it solved. I came to the
            conclusion that allowing the OS to do the CRLF translation was the only
            rational behaviour especially in client server mode.

            Mike
          • Hannu Koivisto
            ... People obviously have different needs. For me, this automatic LF- CRLF translation is really a pain in the ass. My experience in writing portable software
            Message 5 of 10 , Jul 1, 1998
            View Source
            • 0 Attachment
              Mike Pumford <mpumford@...> writes:

              | I tried this once. It caused more problems than it solved. I came to the
              | conclusion that allowing the OS to do the CRLF translation was the only
              | rational behaviour especially in client server mode.

              People obviously have different needs. For me, this automatic
              LF->CRLF translation is really a pain in the ass. My experience
              in writing portable software tells me to keep all source files
              (and for example LaTeX documentation) in LF format. I once
              modified cvs' import command to always import in raw form but I
              didn't modify the rest of the commands (especially checkout) so
              I still had to manually convert CRLF files to LF format in
              Windows environment.

              This is exactly why the original poster's suggestion to make
              this as a toggle would be a very good idea. I would probably fix
              this myself but I currently use cvs only in Linux environment
              (even when writing software for Windows) so this is not a high
              priority issue for me anymore. Still, I hope that some day
              someone solves this problem to make cvs usable to even more
              developers.

              //Hannu
            • Peter Ring
              I m using CVS 1.9.28 in local mode on a Windows NT network with good results, except I think the idea of _automagically_ changing the contents of my source
              Message 6 of 10 , Jul 3, 1998
              View Source
              • 0 Attachment
                I'm using CVS 1.9.28 in local mode on a Windows NT network with good
                results, except
                I think the idea of _automagically_ changing the contents of my source files
                (adding a CR
                before each LF, truncating at first ^Z) stinks.

                While all the 'native' Windows tools that I use accept a single LF (or CR)
                as end-of-line,
                I also use some GNU tools that think a CR before a LF is the last character
                on that line.

                In my Windows NT sandbox, I also maintain some files for Macintosh use.
                These files must have
                a single CR as end-of line.

                For these files, I have these options:
                - tag these files as binary (and loose merge and keywords)
                - convert CR/LF to CR before use on Macintosh (this is what I do)
                - convert CR/LF to LF before use with GNU tools (this is what I do)
                - set up a Mac CVS client, just in order to check out or export Mac files
                But why? None of these options are a natural part of my development work or
                the way
                CVS work.

                And truncating at first ^Z is silly, if not downright unforgiveable.

                I use CVS (among other reasons) because I like concurrent development; of
                course I need to
                be able to distinguish between files that can be merged ('text') and those
                that cannot
                ('binary'). But 'text' files should not automagically imply a particular
                conversions of
                end-of-lines (just because my sandbox is on a Windows NT platform).

                And yes, I did look at the source to see if I could easily change this
                behaviour. I realized
                that there's a whole lot that I don't know anything about, e.g.
                client/server operation.

                Obviously, either 'text' files must be stored in the repository with a
                'canonical' end-of-line,
                or all operations on 'text' files must be immune to differing end-of-lines.

                Can we avoid a new option (read: sticky tag) to specify end-of-line
                conversion? If we need a new
                sticky tag, should it affect the repository or the sandbox?

                And what about backward compatibility?


                Kind regards

                Peter Ring

                > -----Original Message-----
                > From: rausejme@... [mailto:rausejme@...]
                > Sent: 30. juni 1998 08:51
                > To: info-cvs@...
                > Subject: CVS under Windows trashes sandbox checked out under Unix
                >
                >
                >
                > 1. Am I alone in thinking that the CR-LF conversion performed by
                > Windows CVS is a Bad Idea (tm), or at least something that I
                > should be able to disable globally? It causes us nothing but
                > trouble, and all the tools we use under Windows can handle
                > textfiles with bare line feeds just fine.
              • Andreas Pagel
                ... I agree, for the reason you mention: I disabled the translation in our locally modified version of CVS. I m pretty there it was only two lines of code
                Message 7 of 10 , Jul 6, 1998
                View Source
                • 0 Attachment
                  On Tue, 30 Jun 1998, James Rauser wrote:
                  > 1. Am I alone in thinking that the CR-LF conversion performed by
                  > Windows CVS is a Bad Idea (tm), or at least something that I
                  > should be able to disable globally?

                  I agree, for the reason you mention: I disabled the translation in our
                  locally modified version of CVS. I'm pretty there it was only two lines of
                  code where the call to open() needed the O_BINARY flag.

                  Andreas.
                Your message has been successfully submitted and would be delivered to recipients shortly.