Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Juanma Barranquero]

> +   (WARNING: Do NOT use this suggestion if you have write access to the
> +   Emacs CVS tree and intend to commit changes to CVS.  This is because -kb
> +   is sticky: it will be used in all future CVS operations on the files you
> +   check out like this.)

Didn't we discuss this already and concluded that it wasn't a problem?
I know I've committed files from nt/ that I had checked out with -kb.

-- 
                    /L/e/k/t/u

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Eli Zaretskii]

> Date: Sat, 11 Jun 2005 18:33:39 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> 
> > +   (WARNING: Do NOT use this suggestion if you have write access to the
> > +   Emacs CVS tree and intend to commit changes to CVS.  This is because -kb
> > +   is sticky: it will be used in all future CVS operations on the files you
> > +   check out like this.)
> 
> Didn't we discuss this already and concluded that it wasn't a problem?

I asked a question about that, but didn't see any replies.  All my
references, including the CVS manual, indicate that -kb will be used
henceforth with any CVS operation.  If you (or someone else) know
otherwise, please tell the details.

> I know I've committed files from nt/ that I had checked out with -kb.

I never said that committing files will be impossible; binary files
can be committed as well.  The question is, what does CVS think about
these files, and whether all versions have diffs associated etc.

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

>> > +   (WARNING: Do NOT use this suggestion if you have write access to the
>> > +   Emacs CVS tree and intend to commit changes to CVS.  This is because -kb
>> > +   is sticky: it will be used in all future CVS operations on the files you
>> > +   check out like this.)
>> 
>> Didn't we discuss this already and concluded that it wasn't a problem?
>
> I asked a question about that, but didn't see any replies.

Andreas Schwab replyed.

http://lists.gnu.org/archive/html/emacs-devel/2005-06/msg00185.html

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Juanma Barranquero]

> I asked a question about that, but didn't see any replies.

Sorry. I thought you had seen Andreas' reply.

> I never said that committing files will be impossible; binary files
> can be committed as well.  The question is, what does CVS think about
> these files, and whether all versions have diffs associated etc.

That was covered in the message you missed.

-- 
                    /L/e/k/t/u

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Eli Zaretskii]

> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> From: Jason Rumney <jasonr@gnu.org>
> Date: Sat, 11 Jun 2005 22:09:07 +0100
> 
> Andreas Schwab replyed.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2005-06/msg00185.html

Sorry, I missed that somehow.

Anyway, I'm still confused.  Assuming that I checkout a file with -kb,
and that file is not recorded as binary in the repository, would
commands such as "cvs diff", "cvs annotate", etc. work exactly as when
no -kb was ever used on that file?  If that is so, then the CVS people
surely need to redo their manual's description of "co -kb" and of the
binary files issue!

Also, given this description, as written by Andreas:

> > However, AFAIK the -kb option is sticky: it gets written into the
> > file's entry in CVS/Entries, and thereafter all future CVS ops for
> > that file use it.
> 
> This is true, but this is a local-only setting.  If you want to make it
> permanent in the repository you need to use `cvs admin -kb'.  Neither `cvs
> update' nor `cvs checkout' changes the repository.
> 
> > Doesn't that mean that "cvs ci" will also commit the new version as a
> > binary file, will all the consequences of that, like that "cvs diff"
> > will be impossible etc.?
> 
> No.  Only changing the setting in the repository as above will have an
> effect like this.

was this always true, or is this some change in the recent versions of
CVS, and if latter, which version started behaving like that?

And what will "cvs ci" do for a file whose entry in CVS/Entries says
it has the -kb option set?  How will this be different from a file
without the -kb option?

Finally, if "co -kb" indeed has only a local effect, and none of the
other commands, like ci, diff, up -j, etc. are affected, it sounds
like Windows users should be told to checkout the whole tree with -kb,
right?

TIA

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> Anyway, I'm still confused.  Assuming that I checkout a file with -kb,
> and that file is not recorded as binary in the repository, would
> commands such as "cvs diff", "cvs annotate", etc. work exactly as when
> no -kb was ever used on that file?

They seem to, yes.

> Finally, if "co -kb" indeed has only a local effect, and none of the
> other commands, like ci, diff, up -j, etc. are affected, it sounds
> like Windows users should be told to checkout the whole tree with -kb,
> right?

It might be worth trying. AFAIK all the other problems with line ends
have been fixed so it should work.

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Juanma Barranquero]

On 6/12/05, Eli Zaretskii <eliz@gnu.org> wrote:

> Anyway, I'm still confused.  Assuming that I checkout a file with -kb,
> and that file is not recorded as binary in the repository, would
> commands such as "cvs diff", "cvs annotate", etc. work exactly as when
> no -kb was ever used on that file?

cvs diff, annotate, etc. do work as if the files weren't checked out with -kb.

> And what will "cvs ci" do for a file whose entry in CVS/Entries says
> it has the -kb option set?  How will this be different from a file
> without the -kb option?

I think the -kb entry in CVS/Entries does not affect "cvs ci" unless
the file is marked as "-kb" on the repository. None of the commits of
nt/nmake.defs, nt/makefile.w32-in, etc. that I've done seem to have
had any adverse effect.

> Finally, if "co -kb" indeed has only a local effect, and none of the
> other commands, like ci, diff, up -j, etc. are affected, it sounds
> like Windows users should be told to checkout the whole tree with -kb,
> right?

Not sure if they should be told to, but at least there is no problem
if they do: I just checked out a -kb tree and built it with MSVC with
no problem whatsoever.

-- 
                    /L/e/k/t/u

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Eli Zaretskii]

> Date: Tue, 14 Jun 2005 00:52:06 +0200
> From: Juanma Barranquero <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 6/12/05, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Anyway, I'm still confused.  Assuming that I checkout a file with -kb,
> > and that file is not recorded as binary in the repository, would
> > commands such as "cvs diff", "cvs annotate", etc. work exactly as when
> > no -kb was ever used on that file?
> 
> cvs diff, annotate, etc. do work as if the files weren't checked out with -kb.

Thanks for the footwork.  I've now removed the warning from
nt/INSTALL.

> > Finally, if "co -kb" indeed has only a local effect, and none of the
> > other commands, like ci, diff, up -j, etc. are affected, it sounds
> > like Windows users should be told to checkout the whole tree with -kb,
> > right?
> 
> Not sure if they should be told to, but at least there is no problem
> if they do: I just checked out a -kb tree and built it with MSVC with
> no problem whatsoever.

I did that as well (but with MinGW).  I will run with this setup for a
while and see if I encounter any problems.

Re: [Emacs-diffs] Changes to emacs/nt/INSTALL

[Eli Zaretskii]

> Date: Sat, 18 Jun 2005 12:55:04 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > > Finally, if "co -kb" indeed has only a local effect, and none of the
> > > other commands, like ci, diff, up -j, etc. are affected, it sounds
> > > like Windows users should be told to checkout the whole tree with -kb,
> > > right?
> > 
> > Not sure if they should be told to, but at least there is no problem
> > if they do: I just checked out a -kb tree and built it with MSVC with
> > no problem whatsoever.
> 
> I did that as well (but with MinGW).  I will run with this setup for a
> while and see if I encounter any problems.

Found one already: "cvs up" never uses patches with this setup, it
always sends the entire new version of the files downstream.  That is,
if the Emacs tree is checked out with -kb, you will never again see
messages like this:

  P lisp/ChangeLog

but always

  U lisp/ChangeLog

This might be a problem with slow connections, but otherwise it's
harmless, I guess.

A more serious problem is that automatic merges are probably not
supported either (although I didn't try).