| 1 | About |
|---|
| 2 | ===== |
|---|
| 3 | |
|---|
| 4 | Tailor is a tool to migrate changesets between CVS, Subversion_, |
|---|
| 5 | darcs_, monotone_, Codeville_, Mercurial_ and `Baazar-NG`_ [#]_ |
|---|
| 6 | repositories. |
|---|
| 7 | |
|---|
| 8 | This script makes it easier to keep the upstream changes merged in |
|---|
| 9 | a branch of a product, storing needed information such as the upstream |
|---|
| 10 | URI and revision in special properties on the branched directory. |
|---|
| 11 | |
|---|
| 12 | The following ascii-art illustrates the usual scenario:: |
|---|
| 13 | |
|---|
| 14 | +------------+ +------------+ |
|---|
| 15 | +--------------+ | Immutable | | Working | |
|---|
| 16 | | Upstream CVS |-------->| darcs |----------->| darcs | |
|---|
| 17 | | repository | tailor | repository | darcs pull | repository | |
|---|
| 18 | +--------------+ +------------+ +------------+ |
|---|
| 19 | |^ |
|---|
| 20 | || |
|---|
| 21 | || |
|---|
| 22 | v| |
|---|
| 23 | User |
|---|
| 24 | |
|---|
| 25 | Ideally you should be able to swap and replace "CVS server" and "darcs |
|---|
| 26 | repository" with any combination of the supported systems. |
|---|
| 27 | |
|---|
| 28 | A more convoluted setup shows how brave people are using it to get a |
|---|
| 29 | two way sync:: |
|---|
| 30 | |
|---|
| 31 | +----------+ +--------+ +--------+ +---------+ |
|---|
| 32 | | | -----> | hybrid | darcs | | ----> | my | |
|---|
| 33 | | upstream | tailor | CVS | -----> | master | darcs | working | |
|---|
| 34 | | CVS | <----- | darcs | <----- | darcs | <---- | darcs | |
|---|
| 35 | | | | sync | tailor | | | | |
|---|
| 36 | +----------+ +--------+ +--------+ +---------+ |
|---|
| 37 | (cron) (cron) |
|---|
| 38 | |
|---|
| 39 | |
|---|
| 40 | .. [#] Monotone, Codeville, Mercurial and Baazar-NG systems may be |
|---|
| 41 | used only as the `target` backend, since the `source` support |
|---|
| 42 | isn't coded yet. Contributions on these backends will be very |
|---|
| 43 | appreciated, since I do not use them enough to figure out the |
|---|
| 44 | best way to get pending changes and build tailor ChangeSets out |
|---|
| 45 | of them. |
|---|
| 46 | |
|---|
| 47 | .. _subversion: http://subversion.tigris.org/ |
|---|
| 48 | .. _darcs: http://www.darcs.net/ |
|---|
| 49 | .. _codeville: http://www.codeville.org/ |
|---|
| 50 | .. _baazar-ng: http://www.bazaar-ng.org/ |
|---|
| 51 | .. _mercurial: http://www.selenic.com/mercurial/ |
|---|
| 52 | |
|---|
| 53 | |
|---|
| 54 | Installation |
|---|
| 55 | ============ |
|---|
| 56 | |
|---|
| 57 | tailor is written in Python, and thus Python must be installed on |
|---|
| 58 | your system to use it. It has been successfully used with Python 2.3 |
|---|
| 59 | and 2.4. |
|---|
| 60 | |
|---|
| 61 | Since it relies on external tools to do the real work such as `cvs`, |
|---|
| 62 | `darcs` and `svn`, they need to be installed as well, although only |
|---|
| 63 | those you will actually use. |
|---|
| 64 | |
|---|
| 65 | Make tailor executable:: |
|---|
| 66 | |
|---|
| 67 | $ chmod +x tailor |
|---|
| 68 | |
|---|
| 69 | You can either run tailor where it is currently located, or move it |
|---|
| 70 | along with the vcpx directory to a location in your PATH. |
|---|
| 71 | |
|---|
| 72 | There's even a standard setup.py that you may use to install the |
|---|
| 73 | script using Python conventional distutils. |
|---|
| 74 | |
|---|
| 75 | |
|---|
| 76 | Examples |
|---|
| 77 | ======== |
|---|
| 78 | |
|---|
| 79 | 1. Bootstrap a new tailored project, starting at upstream revision 10:: |
|---|
| 80 | |
|---|
| 81 | $ tailor -b -s svn -R http://svn.server/path/to/svnrepo \ |
|---|
| 82 | --module /Product/trunk -r 10 --subdir Product ~/darcs/MyProduct |
|---|
| 83 | |
|---|
| 84 | 2. Bootstrap a new product, fetching from CVS and storing under SVN: |
|---|
| 85 | this will create the directory "~/svnwc/cmfcore"; "~/svnwc" must be |
|---|
| 86 | already under SVN:: |
|---|
| 87 | |
|---|
| 88 | $ tailor --source-kind cvs --target-kind svn --bootstrap \ |
|---|
| 89 | --repository :pserver:cvs.zope.org:/cvs-repository \ |
|---|
| 90 | --module CMF/CMFCore ~/svnwc/cmfcore |
|---|
| 91 | |
|---|
| 92 | 3. Showing each command bootstrap a new DARCS repos in |
|---|
| 93 | "~/darcs/cmftopic" under which the upstream module will be |
|---|
| 94 | extracted as "CMFTopic" (ie, the last component of the module |
|---|
| 95 | name):: |
|---|
| 96 | |
|---|
| 97 | $ tailor -D -b -R :pserver:anonymous@cvs.zope.org:/cvs-repository/ \ |
|---|
| 98 | -m CMF/CMFTopic ~/darcs/cmftopic |
|---|
| 99 | |
|---|
| 100 | 4. Merge upstream changes since last update/bootstrap:: |
|---|
| 101 | |
|---|
| 102 | $ tailor ~/svnwc/MyProduct |
|---|
| 103 | |
|---|
| 104 | 5. Migrate a whole SVN repository, starting from the beginning:: |
|---|
| 105 | |
|---|
| 106 | $ tailor -b -s svn -R svn+ssh://caia/tmp/svn/repo --module / \ |
|---|
| 107 | --subdir testsvn --revision 1 testdir |
|---|
| 108 | |
|---|
| 109 | .. warning:: When using --revision with a SVN source repository, be |
|---|
| 110 | sure that the path your are tracking was there at that |
|---|
| 111 | revision, otherwise svn will exit with an error. |
|---|
| 112 | |
|---|
| 113 | 6. Bootstrap from a CVS branch, starting from a given point in time:: |
|---|
| 114 | |
|---|
| 115 | $ tailor -b -s cvs -R :pserver:anonymous@server.org:/cvsroot/ \ |
|---|
| 116 | --revision 'unstable-branch 2001-12-25 23:26:48 UTC' \ |
|---|
| 117 | --module something new-darcs-repository |
|---|
| 118 | |
|---|
| 119 | 7. Bootstrap from a CVS branch, starting from the beginning of time:: |
|---|
| 120 | |
|---|
| 121 | $ tailor.py -b -s cvs -R :pserver:anonymous@server.org:/cvsroot/ \ |
|---|
| 122 | --revision 'unstable-branch INITIAL' \ |
|---|
| 123 | --module something new-darcs-repository |
|---|
| 124 | |
|---|
| 125 | |
|---|
| 126 | Resolving conflicts |
|---|
| 127 | =================== |
|---|
| 128 | |
|---|
| 129 | Should one of the replayed changes generate any conflict, tailor |
|---|
| 130 | will prompt the user to correct them. This is done after the upstream |
|---|
| 131 | patch has been applied and before the final commit on the target |
|---|
| 132 | system, so that manually tweaking the conflict can produce a clean |
|---|
| 133 | patch. |
|---|
| 134 | |
|---|
| 135 | |
|---|
| 136 | Shortcomings |
|---|
| 137 | ============ |
|---|
| 138 | |
|---|
| 139 | Tailor currently suffers of the following reported problems: |
|---|
| 140 | |
|---|
| 141 | a) It does not handle "empty" CVS checkouts, in other words you cannot |
|---|
| 142 | bootstrap a project that has nothing in its CVS upstream |
|---|
| 143 | repository, or from a point in time where this condition was true. |
|---|
| 144 | |
|---|
| 145 | b) It does not work under Windows (no, that's not a feature :-). Maybe |
|---|
| 146 | replacing the shwrap machinery with something built on top of |
|---|
| 147 | subprocess_ that seems able to hide Windows crazyness... |
|---|
| 148 | |
|---|
| 149 | c) Monotone, Codeville and Baazar-NG are (currently) only supported as |
|---|
| 150 | *target* |
|---|
| 151 | |
|---|
| 152 | d) Specifying ``--subdir .`` may not work, in particular when dealing |
|---|
| 153 | with remote CVS repositories (it does when the CVS repository is |
|---|
| 154 | on local machine). |
|---|
| 155 | |
|---|
| 156 | This list will always be incomplete, but I'll do my best to keep it |
|---|
| 157 | short :-) |
|---|
| 158 | |
|---|
| 159 | .. _subprocess: http://www.lysator.liu.se/~astrand/popen5/ |
|---|
| 160 | |
|---|
| 161 | |
|---|
| 162 | Tailor's metadata |
|---|
| 163 | ================= |
|---|
| 164 | |
|---|
| 165 | To do its work, tailor needs some information about your source tree, |
|---|
| 166 | such as the upstream repository URL and the current revision of the |
|---|
| 167 | sources on your harddisk. |
|---|
| 168 | |
|---|
| 169 | In the simpler case, tailor keeps this information in a file called |
|---|
| 170 | `tailor.info`, one for each tailored project, that is a very simple |
|---|
| 171 | text document, with the following information, one per line: |
|---|
| 172 | |
|---|
| 173 | 1. Upstream repository kind (either "cvs", "darcs" or "svn) |
|---|
| 174 | 2. Target repository kind (the same as above) |
|---|
| 175 | 3. The name of the "module" that's been tailored |
|---|
| 176 | 4. The URL of the upstream repository (that may not be an URL, for cvs...) |
|---|
| 177 | 5. The current revision, from the upstream point of view, of the sources |
|---|
| 178 | 6. The subdirectory that contains the checked out upstream tree, |
|---|
| 179 | either that given with with the `--subdir` option or computed |
|---|
| 180 | taking the last part of the module name. |
|---|
| 181 | |
|---|
| 182 | This is everything tailor needs, to be able to keep going from where it |
|---|
| 183 | left last time. |
|---|
| 184 | |
|---|
| 185 | |
|---|
| 186 | Config file format |
|---|
| 187 | ------------------ |
|---|
| 188 | |
|---|
| 189 | When your project is composed by multiple upstream modules, it is |
|---|
| 190 | easier to collect such information in a single file. This is done by |
|---|
| 191 | specifying the `--configfile` option with a file name as argument. In |
|---|
| 192 | this case, tailor will read/write the above information from a |
|---|
| 193 | standard Python dictionary stored in the given file. |
|---|
| 194 | |
|---|
| 195 | The dictionary is keyed on the relative position of each project, and |
|---|
| 196 | each entry carries the same information described above. |
|---|
| 197 | |
|---|
| 198 | Here's an example config file entry:: |
|---|
| 199 | |
|---|
| 200 | {'plone/atcontenttypes': {'module': 'ATContentTypes', |
|---|
| 201 | 'source_kind': 'cvs', |
|---|
| 202 | 'subdir': 'ATContentTypes', |
|---|
| 203 | 'target_kind': 'darcs', |
|---|
| 204 | 'upstream_repos': ':ext:cvs.sourceforge.net:/cvsroot/collective', |
|---|
| 205 | 'upstream_revision': '2004-11-24 19:42:06 by ctheune'}} |
|---|
| 206 | |
|---|
| 207 | By convention, config files are named with the extension ".tailor", |
|---|
| 208 | but this is not enforced. |
|---|
| 209 | |
|---|
| 210 | In the example above, 'plone/atcontenttypes' is a directory where the |
|---|
| 211 | target source will be stored. The keys such 'module', 'source_kind', |
|---|
| 212 | etc correspond to options of the same name. |
|---|
| 213 | |
|---|
| 214 | When using a config file, tailor will perform its job on each project |
|---|
| 215 | contained in the dictionary. |
|---|
| 216 | |
|---|
| 217 | |
|---|
| 218 | Interactive sessions |
|---|
| 219 | -------------------- |
|---|
| 220 | |
|---|
| 221 | Tailor offers an alternative way of driving its activity by using an |
|---|
| 222 | interactive session, bringing the configuration more similar to a |
|---|
| 223 | script. |
|---|
| 224 | |
|---|
| 225 | Although this is still a work-in-progress, it's quickly becoming my |
|---|
| 226 | preferred usage, as its functionality cover the underlying tailor |
|---|
| 227 | features. |
|---|
| 228 | |
|---|
| 229 | For example, this is the script I'm using to test it:: |
|---|
| 230 | |
|---|
| 231 | cd /tmp |
|---|
| 232 | state_file tailor.state |
|---|
| 233 | source_kind darcs |
|---|
| 234 | target_kind svn |
|---|
| 235 | source_repository /home/lele/WiP/cvsync |
|---|
| 236 | sub_directory cvsync |
|---|
| 237 | refill_changelogs no |
|---|
| 238 | patch_name_format [%(module)s] Changeset %(revision)s by %(author)s |
|---|
| 239 | |
|---|
| 240 | that, as you can see, specifies the context needed by tailor to do its |
|---|
| 241 | work. With the following command line:: |
|---|
| 242 | |
|---|
| 243 | $ tailor --verbose --interactive tailor.cmds |
|---|
| 244 | Welcome to the Tailor interactive session: you can issue several commands |
|---|
| 245 | with the usual `readline` facilities. With "help" you'll get a list of |
|---|
| 246 | available commands. |
|---|
| 247 | |
|---|
| 248 | Current directory: /tmp |
|---|
| 249 | Current state file: /tmp/tailor.state |
|---|
| 250 | Current source kind: darcs |
|---|
| 251 | Current target kind: svn |
|---|
| 252 | Current source repository: /home/lele/WiP/cvsync |
|---|
| 253 | Sub directory: cvsync |
|---|
| 254 | Refill changelogs: False |
|---|
| 255 | Patch name format: [%(module)s] Changeset %(revision)s by %(author)s |
|---|
| 256 | tailor $ help |
|---|
| 257 | |
|---|
| 258 | Documented commands (type help <topic>): |
|---|
| 259 | ======================================== |
|---|
| 260 | EOF print_executed_commands state_file |
|---|
| 261 | bootstrap refill_changelogs sub_directory |
|---|
| 262 | cd remove_first_log_line target_kind |
|---|
| 263 | current_directory save target_module |
|---|
| 264 | exit source_kind target_repository |
|---|
| 265 | logfile source_module |
|---|
| 266 | patch_name_format source_repository |
|---|
| 267 | |
|---|
| 268 | Undocumented commands: |
|---|
| 269 | ====================== |
|---|
| 270 | help |
|---|
| 271 | |
|---|
| 272 | tailor $ help bootstrap |
|---|
| 273 | |
|---|
| 274 | Usage: bootstrap [revision] |
|---|
| 275 | |
|---|
| 276 | Checkout the initial upstream revision, by default HEAD (or |
|---|
| 277 | specified by argument), then import the subtree into the |
|---|
| 278 | target repository. |
|---|
| 279 | |
|---|
| 280 | As another example, consider the following commands:: |
|---|
| 281 | |
|---|
| 282 | cd /tmp/wc |
|---|
| 283 | state_file tailor.state |
|---|
| 284 | source_kind cvs |
|---|
| 285 | target_kind darcs |
|---|
| 286 | source_repository :pserver:anonymous@cvs.sourceforge.net:/cvsroot/buildbot |
|---|
| 287 | source_module buildbot |
|---|
| 288 | refill_changelogs false |
|---|
| 289 | patch_name_format %(firstlogline)s |
|---|
| 290 | print_executed_commands true |
|---|
| 291 | bootstrap 2004/01/01 20:05:24 |
|---|
| 292 | update ask |
|---|
| 293 | |
|---|
| 294 | Assuming ``/tmp/wc`` exists, executing them will first bootstrap a new |
|---|
| 295 | darcs repository with a snapshot at the given date of the upstream |
|---|
| 296 | sources, then will proceed with the update, asking confirmation about |
|---|
| 297 | any single changeset:: |
|---|
| 298 | |
|---|
| 299 | ... |
|---|
| 300 | Collected 586 upstream changesets |
|---|
| 301 | Changeset 2004-01-07 00:42:07 by warner: |
|---|
| 302 | * buildbot/changes/mail.py (parseFreshCVSMail): .... |
|---|
| 303 | * test/test_mailparse.py (Test1.testMsg9): test for same |
|---|
| 304 | |
|---|
| 305 | Apply [Y/n/v/h/q]? h |
|---|
| 306 | y: yes, apply it and keep going |
|---|
| 307 | n: no, skip the current changeset |
|---|
| 308 | v: view more detailed information |
|---|
| 309 | q: do not apply the current changeset and stop iterating |
|---|
| 310 | |
|---|
| 311 | Apply [Y/n/v/h/q]? v |
|---|
| 312 | Revision: 2004-01-07 00:42:07 by warner |
|---|
| 313 | Date: 2004-01-07 00:42:07 |
|---|
| 314 | Author: warner |
|---|
| 315 | Modified: ChangeLog,buildbot/changes/mail.py,test/test_mailparse.py |
|---|
| 316 | Added: test/mail/msg9 |
|---|
| 317 | Log: * buildbot/changes/mail.py (parseFreshCVSMail): ... |
|---|
| 318 | * test/test_mailparse.py (Test1.testMsg9): test for same |
|---|
| 319 | |
|---|
| 320 | Apply [Y/n/v/h/q]? |
|---|
| 321 | |
|---|
| 322 | |
|---|
| 323 | Further help |
|---|
| 324 | ============ |
|---|
| 325 | |
|---|
| 326 | See the output of ``tailor -h`` for some further tips. There's |
|---|
| 327 | also a `wiki page`_ that may give you some other hints. The |
|---|
| 328 | development of Tailor is mainly driven by user requests at this point, |
|---|
| 329 | and the preferred comunication media is the dedicated `mailing list`_ |
|---|
| 330 | [#]_. |
|---|
| 331 | |
|---|
| 332 | .. _wiki page: |
|---|
| 333 | http://www.darcs.net/DarcsWiki/Tailor |
|---|
| 334 | |
|---|
| 335 | .. _mailing list: |
|---|
| 336 | http://lists.zooko.com/mailman/listinfo/tailor |
|---|
| 337 | |
|---|
| 338 | I will be more than happy to answer any doubt, question or suggestion |
|---|
| 339 | you may have on it. I'm usually hanging as "lelit" on the IRC channel |
|---|
| 340 | devoted to darcs on the `freenode.net` network. Do not hesitate to |
|---|
| 341 | contact me either by email or chatting there. |
|---|
| 342 | |
|---|
| 343 | .. [#] I wish to say a big `Thank you` to `Zooko <zooko@zooko.com>`_, |
|---|
| 344 | for hosting the ML and for supporting Tailor in several ways, |
|---|
| 345 | from suggestions to bug reporting and fixing. |
|---|
| 346 | |
|---|
| 347 | |
|---|
| 348 | Author |
|---|
| 349 | ====== |
|---|
| 350 | |
|---|
| 351 | Lele Gaifax <lele@nautilus.homeip.net> |
|---|
| 352 | |
|---|
| 353 | |
|---|
| 354 | Monotone support |
|---|
| 355 | ---------------- |
|---|
| 356 | |
|---|
| 357 | Monotone_ support was kindly contributed by `Markus Schiltknecht |
|---|
| 358 | <markus@bluegap.ch>`_ and further developed by `rghetta |
|---|
| 359 | <birrachiara@tin.it>`_. Since I'm not currently using monotone (so |
|---|
| 360 | little time, so many VCSs...) I'm not in position to test it out |
|---|
| 361 | properly, but I'll do my best to keep it in sync, maybe with your |
|---|
| 362 | support :-) |
|---|
| 363 | |
|---|
| 364 | .. _monotone: http://www.venge.net/monotone/ |
|---|
| 365 | |
|---|
| 366 | |
|---|
| 367 | License |
|---|
| 368 | ======= |
|---|
| 369 | |
|---|
| 370 | Tailor is distribuited under the `GNU General Public License`__. |
|---|
| 371 | |
|---|
| 372 | __ http://www.fsf.org/licensing/licenses/gpl.html |
|---|
| 373 | |
|---|
| 374 | |
|---|
| 375 | About this document |
|---|
| 376 | =================== |
|---|
| 377 | |
|---|
| 378 | This document and most of the internal documention use the |
|---|
| 379 | reStructuredText format so that it can be easily converted into other |
|---|
| 380 | formats, such as HTML. For more information about this, please see: |
|---|
| 381 | |
|---|
| 382 | http://docutils.sourceforge.net/rst.html |
|---|
| 383 | |
|---|
| 384 | |
|---|
| 385 | .. vim:ft=rest |
|---|
| 386 | .. Local Variables: |
|---|
| 387 | .. mode: rst |
|---|
| 388 | .. End: |
|---|