Matt McCutchen's Web SiteRsync materialsFollowing rsync branches  (Top, Following branches with StGIT, Following branches with patchsync, Bottom).  Email me about this page.

Following rsync branches

NOTE: As of 2008-07-29, this is OUT OF DATE.  The branches come as patches again in the "patches" head of the repository.  I will update this page once I establish a workflow for the patches.

Development of rsync comprises a "main"/"trunk" version and numerous maintained patches/branches (39 as of 2008-03-11) that provide additional features.  These patches are primarily a way for rsync users to share the enhancements that they personally find useful without cluttering the main version with special-purpose or low-quality code.

Below is some information about how I followed development of rsync branches in the past.  Now that the branches come as git branches from the official repository instead of patches, I have been mostly just manipulating those branches; I haven't decided if or how I will continue using StGIT.

Following branches with StGIT

As of about 2007-10-13, I followed rsync branches using StGIT on a single source tree and a git repository containing an import of rsync.

Previously, I used my patchsync tool with a separate source tree for the trunk and each branch.  This approach was viable for long-term work on the ACL patch, but when the ACL support was merged into the trunk in rsync 3.0.0, I switched to doing occasional work on a variety of branches.  Setting up and maintaining the large number of source trees that would be required for patchsync would be impractical, whereas StGIT makes it relatively convenient to apply and unapply patches and update them with my changes.

At some point, I might post materials related to my StGIT setup here.  Patchsync may still be a better solution in some situations, so I will leave the information about it posted.

Following branches with patchsync

You can set up patchsync to synchronize a patch in your main rsync source tree with a separate source tree containing the branch.  If you modify one and then run patchsync, it will update the other appropriately; it does the Right Thing without any thought on your part.  Patchsync even happens to use rsync internally.

Patchsync works especially nicely with a CVS checkout of rsync: you can "cvs update" rsync and then run patchsync to update the branch based on changes in the patch.  (However, there's a disadvantage in that edits are merged at the patch level instead of the branch level, which could conceivably cause pointless conflicts; it has never happened to me.)  Conversely, if you change the branch, you can run patchsync and then "cvs diff" to generate a metapatch that others can apply to their checkouts.

If you develop rsync in Eclipse, patchsync works even more nicely if you set it as an external tool builder.  Then using the Eclipse GUI to update rsync automatically updates the branch as well.

Below are the settings and filters files that I use in my patchsync setups of rsync.  Of course, you must rename them to settings and filters when you place them in a staging directory.  Patchsync itself is available here.

FileSizeModification time
patchsync-settings12152007-05-05 16:11:51 +0000
patchsync-filters9432007-05-05 15:35:56 +0000

Change log

This log only has changes since 2007.01.21.


Matt McCutchen's Web SiteRsync materialsFollowing rsync branches  (Top, Following branches with StGIT, Following branches with patchsync, Bottom).  Email me about this page.
Modification time of this page's main source file: 2009-05-06 04:07:54 +0000
Except where otherwise noted, Matt McCutchen waives his copyright to the content of this site.  This site comes with absolutely no warranty.  Why?