Re: When will CVS be replaced by modern version control system?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux