octave-maintainers
[Top][All Lists]
Advanced

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

Re: switching from CVS to Mercurial


From: John W. Eaton
Subject: Re: switching from CVS to Mercurial
Date: Wed, 06 Feb 2008 07:01:00 -0500

On  6-Feb-2008, David Bateman wrote:

| I had a quick look and I have some practical questions. Basically my
| development machine is a laptop and so isn't on line at all times and so
| I can't easily publish the my hg repository directly from my laptop. I
| don't beleive I'll be the only one in that situation. I see a few
| possible solutions

OTOH, having a complete repository on your system when it is offline
has some advantages.  You can generate diffs, commit changes (to be
exported/published later), and clone or branch without having to
contact the mother ship.

| 1) You allow "hg push" to the www.octave.org hg repository,

I don't plan to do this.  I think pushing to a repository that is all
yours is OK (for example, as a means of updating a publicly accessible
repository).  But pushing to a shared repository (the CVS or SVN way
of working) is one of the things that DVCS systems are trying to move
away from.

| 2) Users have their own hg repository on a machine that is "always on"
| that they can push to and you pull from.

Using this method is fine with me and is what I'll be doing (the
archive on octave.org will just be a copy that I push to).  I will
probably not be pulling from very many people, so I don't think it is
important that everyone have a publicly accessible archive.

| This duplication of
| repositories increases the chances that the repositories are out of
| sync.

I guess we'll see if this turns out to be a problem in practice.

| Also not all users will have easy access to a machine that is
| "always on" and has web access for hg to pull from. Where can we host
| these repositories?

Maybe we can convince the savannah admins to support Mercurial, then
Octave developers could host the sources there.  Or, if necessary, I
guess we could buy some hosting somewhere that could be shared by
Octave developers.

| 3) The user uses "hg export" and generates a patchset that they send by
| e-mail. This is not much different from the current situation, but
| essentially looses out on many of the collaborative development
| advantages that mercurial promises.

One difference with changesets is that using hg export/import seems to
eliminate the problem of running patch by hand.  When I get diffs,
sometimes they are made from a subdirectory (or even several) instead
of from the top-level and then they fail to apply cleanly unless I run
patch multiple times in the appropriate directories.  Also, changesets
have author info, so even if I commit a changeset, the name of the
author will appear in the hg log output.  That information is
currently lost with CVS (we could insert it in the commit message, but
that would be extra work).

| What is your preferred collaboration method of the above, or do you have
| any other suggestions?

I think I'd like to be able to pull changes from a few people (you,
Michael, ?) if possible.  Perhaps after they are posted for review, or
not -- I could just pull some changes, then see what's in the set of
changes, review them, then merge only the ones I accept.  I think the
hg view command will help a lot with this as it makes it easy to
browse changesets.

| Do you want patches from now as mercurial patchsets?

Once I actualy switch and start using it, then yes, Mercurial
changesets will be preferred.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]