Changes between Version 15 and Version 16 of TwoWaySync

Timestamp:

08/23/06 23:27:06 (7 years ago)

Author:

lele

Comment:

Use cases

TwoWaySync

@@ -161 +161 @@
 
 __ /tailor/attachment/wiki/TwoWaySync/rednaxela.py
+
+Status
+######
+
+Unfortunately I wasn't able to keep up the good work I started many months ago in a dusty branch of Tailor...
+
+With Zooko's recipe as a possible goal, I started hacking the ConfigurationFile format to allow an easier switch of the source and target backends, simply by tagging a project as ''two-ways'' in its section. This is something that shall be kept, augmented with a more general way of "linking" projects and repositories each other (so that it becomes easier to share and reuse common settings). 
+
+The pending (read never finished) part of changes were
+
+* a different way of splitting the repositories classes than that landed in master repo
+* first reluctant steps toward moving a few peculiarities from the DualWorkingDir to the SourceRepository and TargetRepository abstract and concrete subclasses
+* the highest level of Zooko's recipe, based on the new ability of going ''one'' patch at a time
+
+I'm gonna trash most of these changes.
+
+Given that my own need of a TwoWaySync dropped quite drastically once I felt in love with Darcs, maybe I don't think often enough about the issue to focus it well enough, so I'll write a few notes here.
+
+The typical case
+================
+
+A developer wants to contribute to a well known software which is being developed within a master Subversion repository. He will spend his time mostly on little fixes here and there, and developing a bit more intricated part. He doesn't want to step on main developers feet, so he would like to present clean and well formed patches. Normally, he'd create a branch in the Subversion repository, maybe named after his own name. 
+
+Luckily, he lurked something about Darcs, and starts using it doing the most basic form of TwoWaySync:
+
+1. Check out a current working dir::
+
+    $ svn co http://svn.server/project/trunk project
+
+2. Put everything under darcs too::
+
+    $ cd project
+    $ darcs init
+    $ darcs add --recursive *
+    $ darcs record -a -m "My own hacking start point, from revision r1234"
+
+3. Tag this initial state:
+
+    $ darcs tag initial
+
+4. Until satisfied
+
+   a. Keep up-to-date::
+
+       $ svn update
+
+   b. Hack around, resolving eventual conflicts, maybe even amending already recorded Darcs patches
+
+   c. Record new patches in Darcs, or unrecord and redo some previous ones
+
+5. Commit the whole work to the master repository::
+
+    $ darcs changes --summary --from-tag=initial > /tmp/clog
+    $ svn ci -F /tmp/clog .
+
+Another use case
+================
+
+Another guy develops his products extending and customizing a set of free-software components. He does not appreciate the fact that each one uses a different kind of version control, so he seeks a way of staying as neutral as possible, keeping together his own patches and those coming down from upstream, possibly collaborating with them on some aspects and thus sending now and then a few fixes upstream.
+
+This is harder, because:
+
+1. In this context, obviously the "branches" must survive for a potentially long time
+2. Not all local patches are sent to the other side
+3. Learning and dealing with different types of VC may not be so funny
+
+Can tailor be of any help?
+==========================
+
+... to be continued
+
 }}}