develooper Front page | perl.perl5.porters | Postings from November 2000

Re: rsync'ed patches vs. rsync'ed source (fwd)

Thread Next
From:
John Borwick
Date:
November 6, 2000 09:52
Subject:
Re: rsync'ed patches vs. rsync'ed source (fwd)
Message ID:
Pine.GSO.4.21.0011061251490.8561-100000@eos00du.eos.ncsu.edu
On Mon, 6 Nov 2000, H.Merijn Brand wrote:

> On Fri, 3 Nov 2000 07:36:30 -0600, Jarkko Hietaniemi <jhi@iki.fi> wrote:
> > > I think either this doc should get a place of it's own or the info states
> > > should be integrated in things like perlhack, perlguts and such.
> > 
> > Integrating with perlhack should do fine.
> 
> *** perlhack.pod	Wed Oct  4 20:11:58 2000
> --- perlhack.pod.new	Mon Nov  6 10:13:26 2000
> + To keep in sync with the most recent branch can be done in several
> + ways, but the most convenient and reliable way is using B<rsync>,
> + available at ftp://rsync.samba.org/pub/rsync/ (other ways include ftp).

Keeping in sync with the most recent branch can be done in several ways,
but the most convenient and reliable way is using B<rsync>, available at
ftp://rsync.samba.org/pub/rsync/ .  (You can also get the most recent
branch by FTP.)


> + If you choose to keep in sync using rsync, there are two approaches
> + to do so:

s/do/doing/

> + 
> + =over 4
> + 
> + =item rsync'ing the source tree
> + 
> + Presuming you are in the directory where your perl source resides,

s/,$//

> + and you have rsync installed and available, you can `upgrade' to
> + the bleadperl using:
> + 
> +  # rsync -avz rsync://ftp.linux.activestate.com/perl-current/ .
> + 
> + This takes care of updating every single item in the source tree to
> + the latest applied patch level, creating files that are new (to your
> + distribution) and setting date/time stamps of existing files to
> + reflect the bleadperl status.
> + 
> + You can than check what patch was the latest that was applied by
> + looking in the file B<.patch>, which will show the number of the
> + latest patch.
> + 
> + If you have more than one machine to keep in sync, and not all of
> + them have access to the WAN (so you are not able to rsync all the
> + source trees to the real source), there are some ways to get around
> + this problem.
> + 
> + =over 4
> + 
> + =item Using rsync over the LAN
> + 
> + Set up a local rsync server which makes the rsynced source tree
> + available to the LAN, and sync the other machines towards this

s/,//

s/towards/against/

> + directory.
> + 
> + From http://rsync.samba.org/README.html:
> + 
> +    "Rsync uses rsh or ssh for communication. It does not need to be
> +     setuid and requires no special privileges for installation.  It
> +     does not require a inetd entry or a deamon.  You must, however,
> +     have a working rsh or ssh system.  Using ssh is recommended for
> +     its security features."
> + 
> + =item Using pushing over the NFS
> + 
> + Having the other systems mounted over the NFS, you can take an
> + active pushing approach, in checking the just updated tree against

s/, in/ by/

> + the other not-yet synced trees. An example would be:

s/:$//

> + 
> +   ...... Xsync
> + 
> + Though this is not perfect. It could be improved with checking

s/Though/though/

> + file checksums before updating. Not all NFS systems support
> + reliable utime support (when used over the NFS).
> + 
> + =back
> + 
> + =item rsync'ing the patches
> + 
> + The source tree is maintained by the pumpking who applies patches to
> + the files in the tree. These patches are either created by the
> + pumpking himself using C<diff -c> after updating the file manually or
> + by applying patches sent in by posters on the perl5-porters list.
> + These patches are also saved and rsync'able, so you can apply them
> + yourself to the source files.
> + 
> + Presuming you are in a directory where your patches reside, you can
> + get them in sync with:

s/:$//

> + 
> +  # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
> + 
> + This makes sure the latest available patch is downloaded to your
> + patch directory.
> + 
> + It's then up to you to apply these patches, using something like:

s/:$//

> + 
> +  # last=`ls -rt1 *.gz | tail -1`
> +  # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
> +  # find . -name '*.gz' -newer $last -exec gzcat {} \; >blead.patch
> +  # cd ../perl-current
> +  # patch -p1 -N <../perl-current-diffs/blead.patch
> + 
> + or, since this is only a hint towards how it works, use CPAN-patchaperl
> + from Andreas K├Ânig to have better control over the patching process.
> + 
> + =back
> + 
> + =head3 Why rsync the source tree
> + 
> + =over 4
> + 
> + =item It's easier
> + 
> + Since you don't have to apply the patches yourself, you are sure all
> + files in the source tree are in the right state.
> + 
> + =item It's more recent
> + 
> + According to Gurusamy Sarathy:
> + 
> +    "... The rsync mirror is automatic and syncs with the repository
> +     every five minutes.
> + 
> +     Updating the patch  area  still  requires  manual  intervention
> +     (with all the goofiness that implies,  which you've noted)  and
> +     is typically on a daily cycle.   Making this process  automatic
> +     is on my tuit list, but don't ask me when."

with this quoting style, s/Updating/"Updating/

> + 
> + =item It's more reliable
> + 
> + Well, since the patches are updated by hand, I don't have to say no
> + more ... (see Sarathy's remark).


s/no/any/

> + 
> + =back
> + 
> + =head3 Why rsync the patches
> + 
> + =over 4
> + 
> + =item It's easier
> + 
> + If you have more than one machine that you want to keep in track with
> + bleadperl, it's easier to rsync the patches only once and than apply
> + them to all the source trees on the different machines.

s/than/then/

> + 
> + In case you try to keep in pace on 5 different machines, for which

s/, for which/ and/

> + only one of them has access to the WAN, rsync'ing all the source
> + tree's should than be done 5 times over the NFS, whereas having

s/tree's/trees/

s/NFS, whereas having/NFS.  Having

> + rsync'ed the patches only once, I can apply them to all the source
> + trees automatically. Need I say more ;-)

s/I/you/


> + 
> + =item It's a good reference
> + 
> + If you do not only like to have the most recent development branch,
> + but also like to B<fix> bugs, or extend features, you want to dive
> + into the sources. If you are a seasoned perl core diver, you don't
> + need no manuals, tips, roadmaps, perlguts.pod or other aids to find
> + your way around. But if you are a starter, the patches may help you
> + in finding where you should start and how to change the bits that
> + bug you.
> + 
> + The file B<Changes> is updated on occasions the pumpking sees as his
> + own little sync points. On those occasions, he releases a tar-ball of
> + the current source tree (i.e. perl@7582.tar.gz), which will be an
> + excellent point to start with when choosing to use the 'rsync the
> + patches' scheme. Starting with perl@7582, which means a set of source
> + files on which the latest applied patch is number 7582, you apply all
> + succeeding patches available from than on (7583, 7584, ...).
> + 
> + You can use the patches later as a kind of search archive.
> + 
> + =over 4
> + 
> + =item Finding a start point
> + 
> + If you want to fix/change the behaviour of function/feature Foo, just
> + scan the patches for patches that mention Foo either in the subject,
> + the comments, or the body of the fix. A good change the patch shows

s/change the patch/patch description/ ?

> + you the files that are affected by that patch which are very likely
> + to be the starting point of your journey into the guts of perl.
> + 
> + =item Finding how to fix a bug
> + 
> + If you've found I<where> the function/feature Foo misbehaves, but you
> + don't know how to fix it (but you do know the change you want to
> + make), you can, again, peruse the patches for similar changes and
> + look how others apply the fix.
> + 
> + =item Finding the source of misbehaviour
> + 
> + When you keep in sync with bleadperl, the pumpking would love to
> + I<see> that the community efforts realy work. So after each of his
> + sync points, you are to 'make test' to check if everything is still
> + in working order. If it is, you do 'make ok', which will send an OK
> + report to perlbug@perl.org. (If you do not have access to a mailer
> + from the sytem you just finished successfully 'make test', you can
> + do 'make okfile', which creates the file C<perl.ok>, which you can
> + than take to your favourite mailer and mail yourself).
> + 
> + But of course, as allways, things will not allways lead to a success

s/allways/always/g

> + path, and one or more test do not pass the 'make test'. Before
> + sending in a bug report (using 'make nok' or 'make nokfile'), check
> + the mailing list if someone else has reported the bug already and if
> + so, confirm it by replying to that message. If not, you might want to
> + trace the source of that misbehaviour B<before> sending in the bug,
> + which will help all the other porters in finding the solution.
> + 
> + Here the saved patches come in very handy. You can check in there

s/in there/the list of patches to see/

> + which patch changed what file and what change caused the
> + misbehaviour. If you note that in the bug report, it saves the one
> + trying to solve it, looking for that point.
> + 
> + =back
> + 
> + If searching the patches is too bothersome, you might consider using
> + perl's bugtron to find more information about discussions and
> + ramblings on posted bugs.
> + 
> + =back
> + 
> + =head2 Submitting patches
> + 
>   Always submit patches to I<perl5-porters@perl.org>.  This lets other
>   porters review your patch, which catches a surprising number of errors
>   in patches.  Either use the diff program (available in source code
> ***************
> *** 1451,1456 ****
> --- 1655,1666 ----
>   Keep up to date with the bleeding edge Perl distributions and get
>   familiar with the changes. Try and get an idea of what areas people are
>   working on and the changes they're making.
> + 
> + =item *
> + 
> + Do read the README associated with your operating system, i.e. README.aix

s/i\.e\./e.g./

> + on the IBM AIX OS. Don't hesitate to supply patches to that README if
> + you find anything missing or changed over a new OS release.
>   
>   =item *


Yours,
John Borwick


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About