[OPEN-ILS-DEV] PATCH: utils.[ch] (const correctness)

[Mike Rylander]

On Nov 14, 2007 1:00 PM, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- Mike Rylander <mrylander at gmail.com> wrote:
>
> > On Nov 11, 2007 9:10 PM, Scott McKellar <mck9 at swbell.net> wrote:

[snip]

> Every few days I download copies of the osrf and ils repositories and
> expand them into trunk directory trees.  I haven't really looked at
> woodchip, but if it contains any C I should grab that too.

There's no C in woodchip, AFAIK -- it's all Java.

I'll go through everything from start to finish, as much (or more) for
others on the list that may not have any idea how to grab the code and
start working.

IME, the easiest thing to do, assuming you have a subversion client
installed is to

 $ cd ~
 $ mkdir svn
 $ cd svn
 $ svn co svn://svn.open-ils.org/OpenSRF/trunk/ OpenSRF
 $ svn co svn://svn.open-ils.org/ILS/trunk/ Evergreen

Those commands will create complete checkouts of both repositories.
To update them (at any time, including after changing files -- it will
warn of conflicts and maintain local changes) just cd into the base
directory of each and issue a 'svn up':

 $ cd ~/svn/OpenSRF
 $ svn up
 $ cd ../Evergreen
 $ svn up

That will keep your local working copy in sync with trunk without
messing up your changes.  Generally, it's best to 'svn up' before
starting a hacking session to grab any changes since last you updated
or checked out.

>
> I do my coding and compiling from one big messy directory, plus a
> few subdirectories for headers.  This working directory includes
> various forms of debris such as test drivers, experimental versions,
> and old obsolete stuff.
>
> When I set to work on a given module I copy it from my trunk tree
> into my working directory, edit, compile, and test.  When I'm
> satisfied with the results I copy the modified file into a trunk-mod
> directory tree that parallels the trunk tree.

I generally work right inside a local copy, but however works best for
you is fine.  Subversion won't complain about cruft, and it's default
diff'ing mechanism will ignore anything that the server copy doesn't
know about.

>
> However my trunk-mod tree doesn't mirror everything.  It contains
> only the files that I have modified, and the directories where they
> reside.
>

It's generally easiest to just grab the whole self-contained tree, but
you can actually just grab portions that you care about:

 $ svn co svn://svn.open-ils.org/OpenSRF/trunk/src/libopensrf libopensrf

> Maybe what I need to do is turn my trunk-mod into a full-scale mirror
> of the trunk tree, including (for example) perl and java files that
> I'll never look at.  Then I could do some kind of diff on the entire
> trees.  Is that what you had in mind?
>

Assuming a modified checkout ('svn co ...') of a repository (or some
portion thereof), you can simply cd into the base directory and issue:

 $ svn diff > json-frobinator.patch

It's easiest for me to have a diff from the base of a full checkout,
but I certainly understand wanting to ignore anything you're not
working on, so either would be great.  Hopefully you will gain some
benefit by not having to maintain multiple environments, and patch
creation time should be cut down.

Oh, if  you want to see what local files you've changed (according to
the current server version), just 'svn up' and then issue

 $ svn stat

from the base of the checkout.

Does that help (anyone?)?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com