Maintaining meta-data for patches

[Garrett Cooper]

On Sat, Dec 13, 2008 at 2:33 AM, Romain Tartière <romain at blogreen.org> wrote:
> Hi!
>
> As a port maintainer, you sometimes have to provide patches in your
> ports in order to have a piece of code working.  If you maintain
> projects in a team, you will likely have to handle patches that you
> wrote along with patches that your co-workers have created.
>
> While this situation is not hard to handle while creating the port, it
> is slightly more complex when you want to update the port in question.
> You have to deal with each patch and see if it is still relevant, and
> since you don't have many info about it, you first have to figure out
> what it is supposed to fix.  Generally, you try with / without the patch
> and see if you keep it, but don't go any further (search is the bug has
> been reported upstream, if solutions have been provided upstream, etc.).
>
>
> If I consider for example the port of Mono:
> http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files
>
> We have 13 patches I want to review in order to cleanup the port.
>
> I would like to ask random questions like:
>  - who made this patch? [*]
>  - what is-it supposed to do? [*]
>  - has it been reported upstream? where?
>  - is it fixed in projects trunk upstream?
>  - will it expire at some point (e.g. trunk has been fixed after
>    foo-1.0.1 was tagged so the patch will be useless as soon as foo is
>    at version>1.0.1)
>
> Questions marked with a * can be answered directly using some version
> control system (even if in my case it will not help much since most
> patches come from revision 3: «Initial import: copy of the cvs repo.»).
>
>
> I am so wondering if anyone has ever setup some tools to ease
> collaborative ports maintenance?
>
>
> Thanks!
> Romain

No, but setting up svk is the best way to maintain local patches
against a repository. I have yet to set it up though because I haven't
taken the time to do so yet.
-Garrett