Jesse Keating wrote:
On Thu, 08 Nov 2007 09:31:09 -0500
"Jonathan S. Shapiro" <shap@xxxxxxxxxxx> wrote:
What hg is buying us is the following:
1. I can set up a temporary local workspace, make and retract local
commits, figure out what the heck I was doing, and easily
generate a consolidated commit at the end.
This is VERY helpful when I am multitasking (one problem, one
workspace). It is also very helpful when I am moving work back
and forth between office and home and don't want to commit
centrally yet.
2. We can pull changesets laterally to accept patches or to
collaborate with outsiders for review, and then have the
reviewer push them forward into the central repo.
3. The ability to work on airplanes or in remote locations and
recover when we screw up.
So far, we aren't making a lot of use of patch queues, mainly because
we haven't had time to learn about that much.
I'm not pushing for any change. I'm just trying to answer the workflow
question.
Have you ever found yourself needing to do any of those things within
the context of our Package VCS?
Actually, yes for #1 and #3. #2, I think would go hand in hand with
policies for bringing new packagers in as comaintainers for existing
packages.
Most of the time, we don't think about it because cvs doesn't offer us
the tools to make these workflows possible but it makes sense once you
have the tools.
As an example, when creating the python egg guidelines, I had to try
permutations of package builds that would generate eggs and see what the
pros and cons of each one were. I had to make changes in how eggs were
generated in a providing spec file in one package and changes to how a
package consumed those eggs in another spec file. Because cvs doesn't
have the ability to do #1, I had to create spec files with commented
lines and build a matrix of things I had tried together. Being able to
create a few temporary trees locally would have helped because I could
have committed each alternative to their own local branch, scripted a
test that tried each of the providing branches against each of the
consuming branches, and then only pushed the branch that was proven to
work into the central repository.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
