[prev in list] [next in list] [prev in thread] [next in thread] 

List:       darcs-users
Subject:    Re: [darcs-users] branching
From:       Tommy Pettersson <ptp () lysator ! liu ! se>
Date:       2004-10-05 11:09:19
Message-ID: 20041005110919.GK12559 () lysator ! liu ! se
[Download RAW message or body]

On Mon, Oct 04, 2004 at 02:22:24PM -0700, Keith Irwin wrote:
> My assumption is that a "branch" is simple a copy (get) from a
> self-designated central repo, but then I quickly get messed up  
> thinking about how you keep track of these branches outside of knowing
> where all these check outs reside.

Branches in darcs are very decoupled.  The only thing they
have in common, and what differentiates them from being
totally different repositories, is that they contain some of
the same patches.

Darcs makes it very easy to manage changes within a
branch/repo.  Darcs is also very good at propagating these
changes to other branches/repos, but only on an individual
branch to branch (repo to repo) basis.  There is no support
in darcs for organizing structures of branches (or different
configurations of a repo).

I organize my branches in a tree hierarchy.  I also give them
names starting with _ (underscore), so I can stop recursive
diff and find from entering other branches, and it helps
distinguish them from in-branch directories.  It could look
like this:

  project_dir (not a repo dir itself)
   \_ _rel
   |   \_ _work
   |       \_ _tmp
   |       \_ _complicated_task
   |       |   \_ _sub_task_foo
   |       |   |   \_ _foo_experiment_1
   |       |   |   \_ _foo_experiment_2
   |       |   \_ _sub_task_bar
   |       \_ _some_other_task
   |           \_ _sub_task_gaz
   |           \_ _sub_task_onk
   \_ _rel_1.0
   |   \_ _work
   |       \_ _backport_fix_foo
   |       \_ _backport_fix_bar
   \_ _rel_1.1
       \_ _work
           \_ _backport_fix_foo
           \_ _backport_fix_bar

This is an overcomplicated example; I don't have any project
of this size, but this is how I imagine it will scale (or
fill my disk).

The main idea is that patches only move up or down, and only
one level at a time.  Patches move up when a sub task is ready.
Patches move down to keep sub tasks up to date with changes in
the parent.  Before patches move up (from a leaf), they can be
compiled to larger patches.  This allows for liberate recording
in the leaf branches without later cluttering their parents.
Sub branches are removed as their tasks are finished.

Selected patches are pulled from _work to _rel for a new
release with a new version number.  _rel is the "master"
branch and should never have patches removed.


-- 
Tommy Pettersson <ptp@lysator.liu.se>


[prev in list] [next in list] [prev in thread] [next in thread]