| 1 | About |
|---|
| 2 | ===== |
|---|
| 3 | |
|---|
| 4 | tailor.py is a tool to migrate changesets between CVS, Subversion, and |
|---|
| 5 | darcs repositories. |
|---|
| 6 | |
|---|
| 7 | This script makes it easier to keep the upstream changes merged in |
|---|
| 8 | a branch of a product, storing needed information such as the upstream |
|---|
| 9 | URI and revision in special properties on the branched directory. |
|---|
| 10 | |
|---|
| 11 | The following ascii-art illustrates the usual scenario:: |
|---|
| 12 | |
|---|
| 13 | +------------+ +------------+ |
|---|
| 14 | +--------------+ | Immutable | | Working | |
|---|
| 15 | | Upstream CVS |-------->| darcs |----------->| darcs | |
|---|
| 16 | | repository | tailor | repository | darcs pull | repository | |
|---|
| 17 | +--------------+ +------------+ +------------+ |
|---|
| 18 | |^ |
|---|
| 19 | || |
|---|
| 20 | || |
|---|
| 21 | v| |
|---|
| 22 | User |
|---|
| 23 | |
|---|
| 24 | Ideally you should be able to swap and replace "CVS server" and "darcs |
|---|
| 25 | repository" with any combination of `CVS`, `Subversion` and `darcs`. |
|---|
| 26 | |
|---|
| 27 | |
|---|
| 28 | Installation |
|---|
| 29 | ============ |
|---|
| 30 | |
|---|
| 31 | tailor.py is written in Python, and thus Python must be installed on |
|---|
| 32 | your system to use it. Since it relays on external tools to do the |
|---|
| 33 | real work such as `cvs`, `darcs` and `svn`, they need to be installed |
|---|
| 34 | as well. |
|---|
| 35 | |
|---|
| 36 | Make tailor.py executable:: |
|---|
| 37 | |
|---|
| 38 | $ chmod +x tailor.py |
|---|
| 39 | |
|---|
| 40 | You can either run tailor.py where it is currently located, or move it |
|---|
| 41 | along with the vcpx directory to a location in your PATH. |
|---|
| 42 | |
|---|
| 43 | |
|---|
| 44 | Examples |
|---|
| 45 | ======== |
|---|
| 46 | |
|---|
| 47 | 1. Bootstrap a new tailored project, starting at upstream revision 10:: |
|---|
| 48 | |
|---|
| 49 | $ tailor.py -b -s svn -R http://svn.server/Product -r 10 ~/darcs/MyProduct |
|---|
| 50 | |
|---|
| 51 | 2. Bootstrap a new product, fetching from CVS and storing under SVN: |
|---|
| 52 | this will create the directory "~/svnwc/cmfcore"; "~/svnwc" must be |
|---|
| 53 | already under SVN:: |
|---|
| 54 | |
|---|
| 55 | $ tailor.py --source-kind cvs --target-kind svn --bootstrap \ |
|---|
| 56 | --repository :pserver:cvs.zope.org:/cvs-repository \ |
|---|
| 57 | --module CMF/CMFCore ~/svnwc/cmfcore |
|---|
| 58 | |
|---|
| 59 | 3. Showing each command bootstrap a new DARCS repos in |
|---|
| 60 | "~/darcs/cmftopic" under which the upstream module will be |
|---|
| 61 | extracted as "CMFTopic" (ie, the last component of the module |
|---|
| 62 | name):: |
|---|
| 63 | |
|---|
| 64 | $ tailor.py -D -b -R :pserver:anonymous@cvs.zope.org:/cvs-repository/ \ |
|---|
| 65 | -m CMF/CMFTopic ~/darcs/cmftopic |
|---|
| 66 | |
|---|
| 67 | 4. Merge upstream changes since last update/bootstrap:: |
|---|
| 68 | |
|---|
| 69 | $ tailor.py ~/svnwc/MyProduct |
|---|
| 70 | |
|---|
| 71 | |
|---|
| 72 | Resolving conflicts |
|---|
| 73 | =================== |
|---|
| 74 | |
|---|
| 75 | Should one of the replayed changes generate any conflict, tailor.py |
|---|
| 76 | will prompt the user to correct them. This is done after the upstream |
|---|
| 77 | patch has been applied and before the final commit on the target |
|---|
| 78 | system, so that manually tweaking the conflict can produce a clean |
|---|
| 79 | patch. |
|---|
| 80 | |
|---|
| 81 | |
|---|
| 82 | Shortcomings |
|---|
| 83 | ============ |
|---|
| 84 | |
|---|
| 85 | Tailor currently suffers of the following reported problems: |
|---|
| 86 | |
|---|
| 87 | a) It does not handle "empty" CVS checkouts, in other words you cannot |
|---|
| 88 | bootstrap a project that has nothing in its CVS upstream |
|---|
| 89 | repository, or from a point in time where this condition was true. |
|---|
| 90 | |
|---|
| 91 | b) It does not work under Windows (no, that's not a feature :-). Maybe |
|---|
| 92 | replacing the shwrap machinery with something built on top of |
|---|
| 93 | subprocess_ that seems able to hide Windows crazyness... |
|---|
| 94 | |
|---|
| 95 | This list will always be incomplete, but I'll do my best to keep it |
|---|
| 96 | short :-) |
|---|
| 97 | |
|---|
| 98 | .. _subprocess: http://www.lysator.liu.se/~astrand/popen5/ |
|---|
| 99 | |
|---|
| 100 | |
|---|
| 101 | Tailor's metadata |
|---|
| 102 | ================= |
|---|
| 103 | |
|---|
| 104 | To do its work, tailor needs some information about your source tree, |
|---|
| 105 | such as the upstream repository URL and the current revision of the |
|---|
| 106 | sources on your harddisk. |
|---|
| 107 | |
|---|
| 108 | In the simpler case, tailor keeps this information in a file called |
|---|
| 109 | `tailor.info`, one for each tailored project, that is a very simple |
|---|
| 110 | text document, with the following information, one per line: |
|---|
| 111 | |
|---|
| 112 | 1. Upstream repository kind (either "cvs", "darcs" or "svn) |
|---|
| 113 | 2. Target repository kind (the same as above) |
|---|
| 114 | 3. The name of the "module" that's been tailored |
|---|
| 115 | 4. The URL of the upstream repository (that may not be an URL, for cvs...) |
|---|
| 116 | 5. The current revision, from the upstream point of view, of the sources |
|---|
| 117 | 6. The subdirectory that contains the checked out upstream tree, |
|---|
| 118 | either that given with with the `--subdir` option or computed |
|---|
| 119 | taking the last part of the module name. |
|---|
| 120 | |
|---|
| 121 | This is everything tailor needs, to be able to keep going from where it |
|---|
| 122 | left last time. |
|---|
| 123 | |
|---|
| 124 | |
|---|
| 125 | Config file format |
|---|
| 126 | ------------------ |
|---|
| 127 | |
|---|
| 128 | When your project is composed by multiple upstream modules, it is |
|---|
| 129 | easier to collect such information in a single file. This is done by |
|---|
| 130 | specifying the `--configfile` option with a file name as argument. In |
|---|
| 131 | this case, tailor will read/write the above information from a |
|---|
| 132 | standard Python dictionary stored in the given file. |
|---|
| 133 | |
|---|
| 134 | The dictionary is keyed on the relative position of each project, and |
|---|
| 135 | each entry carries the same information described above. |
|---|
| 136 | |
|---|
| 137 | Here's an example config file entry:: |
|---|
| 138 | |
|---|
| 139 | {'plone/atcontenttypes': {'module': 'ATContentTypes', |
|---|
| 140 | 'source_kind': 'cvs', |
|---|
| 141 | 'subdir': 'ATContentTypes', |
|---|
| 142 | 'target_kind': 'darcs', |
|---|
| 143 | 'upstream_repos': ':ext:cvs.sourceforge.net:/cvsroot/collective', |
|---|
| 144 | 'upstream_revision': '2004-11-24 19:42:06 by ctheune'}} |
|---|
| 145 | |
|---|
| 146 | By convention, config files are named with the extension ".tailor", |
|---|
| 147 | but this is not enforced. |
|---|
| 148 | |
|---|
| 149 | In the example above, 'plone/atcontenttypes' is a directory where the |
|---|
| 150 | target source will be stored. The keys such 'module', 'source_kind', |
|---|
| 151 | etc correspond to options of the same name. |
|---|
| 152 | |
|---|
| 153 | When using a config file, tailor will perform its job on each project |
|---|
| 154 | contained in the dictionary. |
|---|
| 155 | |
|---|
| 156 | |
|---|
| 157 | Further help |
|---|
| 158 | ============ |
|---|
| 159 | |
|---|
| 160 | See the output of tailor.py -h for some further tips. There's also a |
|---|
| 161 | `wiki page`_ that may give you some other hints. |
|---|
| 162 | |
|---|
| 163 | .. _wiki page: |
|---|
| 164 | http://www.scannedinavian.org/DarcsWiki/ConvertingFromSubversion |
|---|
| 165 | |
|---|
| 166 | I will be more than happy to answer any doubt, question or suggestion |
|---|
| 167 | you may have on it. I'm usually hanging as "lelit" on the IRC channel |
|---|
| 168 | devoted to darcs on the `freenode.net` network. Do not hesitate to |
|---|
| 169 | contact me either by email or chatting there. |
|---|
| 170 | |
|---|
| 171 | |
|---|
| 172 | Author |
|---|
| 173 | ====== |
|---|
| 174 | |
|---|
| 175 | Lele Gaifax <lele@nautilus.homeip.net> |
|---|
| 176 | |
|---|
| 177 | |
|---|
| 178 | About this document |
|---|
| 179 | =================== |
|---|
| 180 | |
|---|
| 181 | This document and most of the internal documention use the |
|---|
| 182 | reStructuredText format so that it can be easily converted into other |
|---|
| 183 | formats, such as HTML. For more information about this, please see: |
|---|
| 184 | |
|---|
| 185 | http://docutils.sourceforge.net/rst.html |
|---|
| 186 | |
|---|
| 187 | |
|---|
| 188 | .. vim:ft=rest |
|---|
| 189 | .. Local Variables: |
|---|
| 190 | .. mode: rst |
|---|
| 191 | .. End: |
|---|
