Status: obsolete; 2007-2008
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.
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.
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.
| File | Size | Modification time |
|---|---|---|
| patchsync-settings | 1215 | 2007-05-05 16:11:51 +0000 |
| patchsync-filters | 943 | 2007-05-05 15:35:56 +0000 |
This log only has changes since 2007.01.21.