This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Setup.exe "other URL" functionality



===
----- Original Message -----
From: "Gary R. Van Sickle" <g.r.vansickle@worldnet.att.net>
> > You should be ok with text mounts now, I think this problem cropped
up
> > due to the CRLF's in the repository. I'm checking in a new version
asap.
> >
>
> Ok, thanks.  As of this writing I don't see it yet - did you want me
to re-diff
> 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.

Rob

> > 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";
> > + "\n%%% $Id: choose.cc,v 2.81 2001/12/23 12:13:28 rbcollins Exp
$\n";
> > ==
> >
> > Is a sure sign that your repository is out of date. (That's one
reason
> > those lines exist :]).
>
> Oh I know it is (well, was).  With cvs in a not-working-for-me state I
figured
> 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
patches
> since my last patch, which I figured since my change was so minimal
would not
> 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
man cvs
> 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
you
> > 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
patch,
...
> Yeah, and I apologize if this is causing you a bunch of grief.  I
certainly had
> no intention of sloughing off a bunch of work onto you or anybody
else.

Apology accepted - no big deal.

> I did in fact review the patch, clearly not as thouroughly as I should
have, in
> addition to writing the ChangeLog in parallel with the code changes.
Again
> 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
got 80
> 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
happening.
> >
>
> At the risk of sounding even more defensive ;-), I am in that habit
(at least
> 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
this....

> > 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
where the
> action was.  Right now I'm seeing no difference, but will do from now
on.

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
HEAD).
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.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]