[Bese-devel] Re: dom-id's in xxx-select-field elements

[Lou Vanek]

Marijn Haverbeke wrote:

> On 6/8/06, *Lou Vanek* <vanek at acd.net <mailto:vanek at acd.net>> wrote:
> 
>     I would go ahead and make the changes, create a few patches,
>     and submit 'em. What's the worst that can happen? You get
>     a code base that's more to your liking (it's partially YOUR
>     code), and Marco may decide not to merge your changes. But that
>     doesn't change the fact that you have changed ucw more to your
>     liking. Your changes remain intact every time you run darcs
>     (unless of course the SELECT code is changed in the future, but
>     then you can simply refuse that patch). 
> 
> 
> Great, I'll do that. I haven't worked much with darcs before - What is 
> the best way to submit a patch?
> 
> Marijn

CREATE A PRISTINE UCW DIRECTORY

Create a new ucw directory so that you have something to compare to.

'cd' to where you want a new ucw directory to be created,
and get one of the darcs repositories:

   darcs get http://common-lisp.net/project/ucw/repos/ucw_dev

or, for the more adventurous soul who wants ajax:

   darcs get http://common-lisp.net/project/ucw/repos/ucw_ajax

Later, these directories can be updated by 'cd'ing into their
top level and doing a 'pull' instead of a 'get':

   darcs pull http://common-lisp.net/project/ucw/repos/ucw_dev

I put this command in a simple shell script and have it run everyday so
my code is up to date and I don't run into problems that have already
been fixed.

CREATE THE PATCH

This is one way:

   LC_ALL=C diff -Naurbdwt -x '*.fas' -x '*.lib' -x _darcs -x docs -x bin -x 'READ*' -I '^\s*;' ucw_dev ucw_dev.my

This says,
   LC_ALL=C     standardize my environment before creating the patch because the patch
                must also be able to work on other computers
   -Naurbdwt    bunch of options that can be found in the diff man page
   -x '*.fas'   ignore all lisp compiled files (I use Clisp. Your compiled files may be different)
   -x _darcs    ignore the darcs repository
   -x docs      ignore the docs directory
   -I '^\s*;'   ignore comment lines common to both files being compared

and recursively compare the clean directory 'ucw_dev' with my modified directory 'ucw_dev.my'.
I run commands in bash so this command would also work in sh and probably csh. Don't know
about DOS shell, though. Probably not so much.

I would put this command in a shell script because I might run it later. Call it something
like diff_ucw_dev.bash, then 'cd' one level above 'ucw_dev' and run it to create the patch:

   diff_ucw_dev.bash > my_super_duper_patch

This text file can be posted to the NG if it's not too large, either directly into email
or as attachments. It would probably have to be directly emailed to Marco if it was
larger than, say, 25K, because many NGs/MLs automatically filter out large postings.

REVIEWING AND MODIFYING THE PATCH (OPTIONAL)

The patch is just a text file so you can easily see the differences it found.

You probably don't want to send every nit in the patch, so you can do one of two things.
Either change your code to comply with the "clean" ucw_dev (and recreate the patch),
or do minor surgery on the patch itself.

After reviewing the changes in the patch, if there is one change you don't want sent
you can open the patch file up and manually delete the offending 'chunk' and the patch
will still work as long as you excise the entire 'chunk' en toto:
. the file names preceding the chunk
. the line numbers of the chunk you don't want to send
. the chunk's actual text that you don't want included in the patch

APPLYING THE PATCH

After receiving a patch, somebody (such as Marco) can apply it by 'cd'ing to the same
place in the directory structure where the patch was created, and run,

   patch -Np0 < my_super_duper_patch

and, if he decides he doesn't like the results of the patch, he can reverse it,

   patch -NRp0 < my_super_duper_patch

(Those are zeros, not ohs, in the options.)

It's up to you to tell the person who is applying the patch which directory to start in,
but anybody should be able to figure it out easily just be opening the patch up in a text
editor and looking at the file names (which is why I don't bother).

I would save my_super_duper_patch because it's possible that a darcs patch will stomp on
something you did. Darcs will usually tell you when there is a merge conflict, and you will
have to manually go in and decide which blob of text to keep. But if something screwed up
you may want to apply your patch to your own code later.

Lou
--
My windows box has been up for over 6 days without requiring a reboot.
I think that's a personal best.