This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Setup.exe "other URL" functionality
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>,<cygwin-patches at sourceware dot cygnus dot com>
- Date: Thu, 3 Jan 2002 20:41:21 +1100
- Subject: Re: [PATCH] Setup.exe "other URL" functionality
- References: <NCBBIHCHBLCMLBLOBONKAEDICIAA.email@example.com>
----- Original Message -----
From: "Gary R. Van Sickle" <firstname.lastname@example.org>
> > You should be ok with text mounts now, I think this problem cropped
> > due to the CRLF's in the repository. I'm checking in a new version
> Ok, thanks. As of this writing I don't see it yet - did you want me
> now that I'm able to cvs update (and have done so)?
No.. I'm waiting for your missing changelog smippet to do the checkin.
> > I'd like to point something out to you:
> > ==
> > - "\n%%% $Id: choose.cc,v 2.82 2002/01/01 12:32:36 rbcollins Exp
> > + "\n%%% $Id: choose.cc,v 2.81 2001/12/23 12:13:28 rbcollins Exp
> > ==
> > Is a sure sign that your repository is out of date. (That's one
> > those lines exist :]).
> Oh I know it is (well, was). With cvs in a not-working-for-me state I
> trying to sync up would be futile at best and counterproductive at
worst. I had
> been monitoring the cygwin-cvs list and only saw Chris' Makefile.in
> since my last patch, which I figured since my change was so minimal
> cause too much trauma.
> BTW, you mentioned I should add this to my new files - what's being
keyed off of
> here (i.e. what do I put in the first one?)? I didn't see anything in
> or /usr/doc/cvs-whatever/ explaining this.
"\n%%% $Id$\n" is the string constant.
> > Another is to put your ChangeLog into the
> > ChangeLog file - if it shows anything other than your changelog when
> > create the diff, something has been checked in and raced with you.
> Right, but I thought diffed ChangeLogs were taboo?
Yeah well, I'm not Chris :]. You do need to send in a straight forward
separate file with the ChangeLog regardless (for posterity), but I'll
never reject a patch for diffing ChangeLog itself.
> > I *think* I've got every change I committed eliminated from your
> Yeah, and I apologize if this is causing you a bunch of grief. I
> no intention of sloughing off a bunch of work onto you or anybody
Apology accepted - no big deal.
> I did in fact review the patch, clearly not as thouroughly as I should
> addition to writing the ChangeLog in parallel with the code changes.
> about all I can do is apologize; but hey, you did notice the strict
> 80-columness, right? Oh yeah, that journey of a thousand miles just
> columns shorter ;-).
Woohoo! I should remember the Ass-U-Me rule of assumptions :}. Thanks
for going through these hoops - I do try to keep them as low to the
ground as possible.
> > Also, please get it the habit of
> > cvs -z3 update -Pd && cvs -z3 diff -up > foo.patch
> > to reduce the chances of diffing against an old sandbox from
> At the risk of sounding even more defensive ;-), I am in that habit
> since the last patch), but again with cvs broke and me not knowing
what the heck
> was going on etc etc... well, second verse, same as the first. ;-)
You have a good excuse there :]. We'll just get CVS patched to handle
> > Another way to prevent this is to checkout with -D 'now' (or if that
> > barfs -D '1 minute ago') which will cause the sandbox to be diffed
> > against the version you checked out, not the HEAD tag.
> Oh, um, ok, for some reason I got the idea that on this one HEAD was
> action was. Right now I'm seeing no difference, but will do from now
HEAD is where the action is. There are 2 main routes to clean patches:
1) An up to date sandbox (w.r.t. whatever tag you are tracking - ie
2) A point-in-time sandbox (-D "point in time").
2) is ideal if you are making major changes that you expect I might
break, or need a stable environment yourself for a while. Your diff when
it's created will occasionally fail to apply due to bad context (if the
context changes from -D"point in time" to HEAD, but if you tell me
the -D "point in time" you used (GMT required!) I can zip to that point
in time, apply your patch, and roll it forward easily.