[general] Patch preparation workflow Was: [classlib][pack200] Status update (again)

[Salikh Zakirov <Sa...@Intel.com>]

Alex Blewitt wrote:
> I think patching is a great way of making the occasional change to
> existing code. I don't think it works well for new development.

Alex,

have you tried any of the modern distributed version control systems?
Here are some:
  Monotone: http://monotone.ca
  Mercurial(hg): http://www.selenic.com/mercurial
  Git: http://git.or.cz

Any of the above is capable of storing and managing multiple patches and
branches in the local repository, all of them support file renames (although in
different ways) and advanced merging.

The basic techniques of preparing patches for Harmony is:

1) create a separate "tracking" branch as an exact copy of Harmony SVN
   (you can do 'svn checkout' and commit to a local version control,
    or use some importer like Tailor http://www.darcs.net/DarcsWiki/Tailor)

2) create a local branch for your development

3) when you want to merge with SVN trunk, first update the tracking branch
   (without your local modifications), and then merge tracking branch
   into your working branch.

4) produce updated patch as the difference between updated tracking branch
   and updated working branch.

It looks like this is a quite common workflow, and googling may get many
descriptions and success stories.

So I think, "patching" is good as a means of exchanging code modifications,
but you may need some additional tools to manage patches while you develop
them.

Re: [general] Patch preparation workflow Was: [classlib][pack200] Status update (again)

[Alex Blewitt <al...@gmail.com>]

Let's be clear; the problems aren't me being able to keep up with
changes in Harmony. There's not that much work in the pack200 package
other than what I'm doing anyway.

The big problem is that the refactoring and on-going development
results in the SVN copy not being able to generate a patch which other
Harmony commiters can then use. My local repository is fine, and I can
develop with it; the problem is getting this data out and into
Harmony.

Alex.

On 24/11/06, Salikh Zakirov <Sa...@intel.com> wrote:
> Alex Blewitt wrote:
> > I think patching is a great way of making the occasional change to
> > existing code. I don't think it works well for new development.
>
> Alex,
>
> have you tried any of the modern distributed version control systems?
> Here are some:
>   Monotone: http://monotone.ca
>   Mercurial(hg): http://www.selenic.com/mercurial
>   Git: http://git.or.cz
>
> Any of the above is capable of storing and managing multiple patches and
> branches in the local repository, all of them support file renames (although in
> different ways) and advanced merging.
>
> The basic techniques of preparing patches for Harmony is:
>
> 1) create a separate "tracking" branch as an exact copy of Harmony SVN
>    (you can do 'svn checkout' and commit to a local version control,
>     or use some importer like Tailor http://www.darcs.net/DarcsWiki/Tailor)
>
> 2) create a local branch for your development
>
> 3) when you want to merge with SVN trunk, first update the tracking branch
>    (without your local modifications), and then merge tracking branch
>    into your working branch.
>
> 4) produce updated patch as the difference between updated tracking branch
>    and updated working branch.
>
> It looks like this is a quite common workflow, and googling may get many
> descriptions and success stories.
>
> So I think, "patching" is good as a means of exchanging code modifications,
> but you may need some additional tools to manage patches while you develop
> them.
>
>