From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Warren Turkal <wt(at)penguintechs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SCMS question |
Date: | 2007-02-23 22:42:12 |
Message-ID: | 20070223224212.GC6210@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> My typical cycle is to take the patch, apply it to my tree, then cvs
> diff and look at the diff, adjust the source, and rerun until I like the
> diff and apply. How do I do that with this setup?
The same, except that you don't need to take the patch out of an email
and into the repository -- the new code is already in the repository,
sitting in someone's own branch. You can commit into that branch all
the adjustments you want; and when you consider it ready, the only thing
you have to do is "propagate" the change to the main development branch.
Yes, it's nice. Consider this: Andrew develops some changes to PL/perl
in his branch. Neil doesn't like something in those changes, so he
commits a fix there. In the meantime, Tom has been busy with his own
stuff and committing to the main branch; Andrew can track those changes
by propagating from the main branch to his branch -- he doesn't need to
fall behind and update his modified tree once a month and deal with
umpteen conflicts.
Of course, you can _also_ do the patch by email and correct stuff if you
want. It's just not the best way to do it.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-02-23 22:44:41 | Re: [HACKERS] Re: 5 Weeks till feature freeze or (do you know where your patch is?) |
Previous Message | Jim C. Nasby | 2007-02-23 22:38:27 | Re: Priorities for users or queries? |