When will CVS be replaced by modern version control system?
a.badger at gmail.com
Thu Nov 8 17:21:56 UTC 2007
Jesse Keating wrote:
> On Thu, 08 Nov 2007 09:31:09 -0500
> "Jonathan S. Shapiro" <shap at eros-os.com> 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
> 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
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.
More information about the fedora-devel-list