On Mon, May 25, 2009 at 02:07:01PM -0400, Scott Gifford wrote:
> Aaron Zeckoski <azeckoski_at_vt.edu> writes:
>
> > I want to manage a small number of changes to a large chunk of code
> > (PHP) from an external project such that when I commit I am only
> > committing the stuff I added or changed and not the rest of the
> > code. The original code is not located in an SVN repository and
> > license stuff means I cannot really put it in into my repository
> > either. Is there any way to manage this? (if this is documented
> > somewhere then please just send along the link)
>
> I managed this for awhile by keeping a "patches" directory in SVN.
> Whenever I changed something in the original, I would generate a patch
> with diff, then update that diff in SVN.
> That worked OK, but quickly got very tedious and error-prone.
Subversion cannot do this well.
Mercurial patch queues have been designed for this use case,
however, and it's really nice to use:
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
I'd say for people who want to contribute patches to an upstream
project without loosing track of what they're doing, Mercurial
patch queues is the way to go.
For people who want to manage a variant of an externally maintained
code base over a longer period of time, and don't necessarily aim
to contribute back, vendor branching is much better.
Either approach can be bent to serve the use case of the other
but the result of doing that is never really nice.
Stefan
Received on 2009-05-25 20:28:35 CEST