On Thu, 2007-02-22 at 14:49 -0300, Alvaro Herrera wrote:
> For example, currently if I have a patch and somebody reviews it and
> opines that I have to change foo to bar; then I resubmit the patch. How
> do they find out whether I actually changed foo to bar? Currently there
> are two alternatives:
>
> 1. trust that I did it
> 2. review the whole patch again
Or use interdiff, and then review the incremental changes.
BTW, I think an important benefit of switching to a distributed SCM is
that it could make life significantly simpler for people maintaining
long-lived branches of the Postgres source. That includes both
individual developers working on complex features, but also companies
that maintain a branch/fork of the Postgres source for one reason or
another. At the moment, this requires considerable manual effort: people
often end up manually importing periodic snapshots of the upstream
Postgres source into their SCM system at various times, and then merging
the changes with their private tree by hand.
Personally, I'd definitely be in favour of evaluating the alternative
SCMs, and switching *at some point*, although it may be that none of the
alternatives are mature enough for us to switch yet. In the past, I've
converted the Postgres CVS tree to both darcs and monotone. Darcs was
completely unusable: even though I didn't import the initial CVS
revision history, after a few months of merging in upstream fixes via
Tailor, the merging process began to take days of CPU time (before I
killed it off). So unless the Darcs algorithms change fundamentally from
the 1.0.4-era approach, I don't think it would be scalable enough for
us.
Monotone worked pretty well -- I'd include it in the set of plausible
SCM candidates, along with Mercurial. I agree with Andrew that there's
not much to be gained by switching to SVN.
-Neil