Re: Push to all repositories

From: Enrico Weigelt <weigelt@metux.de>
Date: Jan 2, 2011, 09:54 UTC
Message-ID: <20110102095425.GA7061@nibiru.local>
In-Reply-To: <20101209195204.GB6884@burratino>

* Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 29 quoted lines

> Consider a project in a patches+tarballs workflow.  It begins like
> this:
> 
>  1. Acquire a tarball with the version you want to base your work on.
>  2. Untar.
>  3. Copy the result to save the current state.
>  4. Test it.
>  5. Fix a bug or add a feature.
>  6. Make a patch with "diff -pruN"
>  7. Return to step 3.
>     ...
>  8. Looks good; email out the patches to get some feedback.
> 
> Now another person wants to test the patches; so she tries:
> 
>  1. Acquire a tarball with the version you want to test against.
>  2. Untar.
>  3. Apply patches with "patch -p1".
> 
> Wait a second --- the patches don't apply!  Or worse, they
> apply but the result is broken.  Okay:
> 
>  4. Complain to the patch author.
> 
> Finally the patch author has more work to do:
> 
>  9. Acquire a newer tarball, and use either "patch --reject-file"
>     or rcs "merge" to reconcile the differences.  Email out the
>     result.

Compared to git:

1. Clone repo and checkout the desired version
2. Fix a bug or add a feature and commit to your local branch
3. Do your tests and cleanups (eg. cleanups w/ interactive rebase)
3. Push your branch to some place others can catch it and
   announce it to others

Now another person wants to test your version:

1. Clone your repo and checkout your branch.
--> there is nothing that could fail to apply - everything's consistant
    by design (assuming the repo was cleanly cloned ;-o)
2. Possibly become an author yourself:
   a. rebase to a newer upstream version
   --> same as above

Show 10 quoted lines

> The result is a sequence of snapshots that have been _tested_ to work
> correctly.  Now compare the svn workflow I briefly used at work:
> 
>  1. svn update
>  2. hack hack hack
>  3. svn update
>  4. hack hack hack
>  5. svn update
>  6. hack hack hack
>  7. send out a patch for feedback

SVN has a quite bad idea of branches and isn't even near to support things like rebasing anyhow.

> Unfortunately, the version committed (1) does not reflect the
> development history and (2) is not even tested, if changes
> happened in trunk between step 9 and step 10.

The idea of having everything in a big trunk is, aehm, quite suboptimal.
Better: have each issue in its own branch, that gets rebased to the
mainline frequently and merged back there when properly tested.

Show 5 quoted lines

> Of course in the opposite direction is
> 
>  - changes to workflow can be hard for a team to adjust to
> 
> (i.e., "don't fix what isn't broken").

Well, many people tend to stick in old ideas (including workflows), no matter what newer developments are made. I currently have to cope with that in an customer project: most of the people here don't even consider using branches since the only vcs'es they know have no really usable support for this (TFS, etc ;-o), and they refuse to learn something new as long as their old way seems to work somehow (no matter of costs). I've estimated the productivity loss caused by sticking backwards cruft like TFS on factors of 5..10 - nobody cares. (actually, not really bad for me: the longer it takes, the more money I earn ;-P)

cu

-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------