* Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> 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
> 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.
> 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@xxxxxxxx
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html