Patch mgmt workflow proposal

[martin f krafft]

also sprach Ben Finney <bignose+hates-spam at benfinney.id.au> [2011.08.02.0229 +0200]:
> >   1. you develop your features on branches, but you do not push the
> >      branch heads;
> 
> Right. The feature branches stay only with the people who are
> interested; usually the people actually working on each one.

You do need to ensure that everyone has the objects they reference,
as these objects are used to generate the patches.

> >   4. at a later stage, when someone wants to edit a patch, they can
> >      create a branch off the SHA-1, merge the branch into the build
> >      branch and provide the updated patch (with updated SHA-1), or
> >      just provide an updated patch file and let the maintainer
> >      update the branch with an interdiff.
> 
> With Bazaar, the branches have their own distinct existence, and can be
> re-created at will by anyone who has the identifier. Is that the same
> for Git?

Yes. Git's branches are just human-readable aliases for SHA-1's,
with the added functionality that a commit advances them to the
child.

> > I see an advantage in this approach because it focuses on
> > debian/patches/* rather than using a potentially-confusing set of
> > branch heads.
> >
> > However, it employs a possibly brittle way to keep track of branch
> > heads (SHA-1's in text files).
> 
> I don't see that brittleness; maybe that's because of the way Bazaar
> keeps track of merges explicitly.

I don't think it has anything to do with merges. The brittleness
comes from the fact that we are storing a text-representation of an
implementation detail in a content blob in the repository. This
is redundant information in a place that users might well touch with
their text editors, and this means that the redundant information
could go out-of-sync.

> > The thing I do not like about it is that the build branch has all
> > features merged (hence applied to the worktree), *in addition* to
> > tracking the generated patch files in debian/patches/* in the
> > repository.
> 
> That's a big plus, in my view; but then again Bazaar has the sensible
> default of hiding merged revision data until it's requested by the user.

Why is it a plus? If you already applied all changes, why bother
exporting the patches?

Thanks for your time,

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"if ever somethin' don't feel right to you, remember what pancho said
 to the cisco kid...  `let's win, before we are dancing at the end of
 a rope, without music.'"
                                                             -- sailor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20110802/af374de8/attachment.pgp>