glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] mercurial switch


From: Kai Antweiler
Subject: Re: [glob2-devel] mercurial switch
Date: Fri, 20 Apr 2007 21:26:50 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux)

> * We can have automatical emails send to the mailing list, when
>>   the data repository changes.  (If you have a mail server)
>
>
> NO! Wouldn't this result in 1000's emails a month. This mailing list is
> already busy enough.

Not if this is only triggered by new graphics.


Today I have tested the "hg branch" command:
* The branch command works like cvs branches.  They are only sticky tags.
* The orignal main branch has no name and therefore can not be selected.
  We can give it a name, but only after current revision upwards.
* When you forget to say which branch you want when pulling, you will
  get the whole repository.
* When you forget to say which branch you want when pushing, you will
  push the whole repository.


I also thought about the recommended mercurial branch == repository
handling.  Creating a new branch would mean sending the whole created
repository over the network again.  This is definitely not good.
If we'll use repository == branch, we'll need to create a branch
repository on Stephs server for each new branch, and then only sync it
with a developers branch at home.
"hg clone" has a "--remotecmd" option.  This should work.

Pulling a branch into another would have the same problem, but this
would be less data to transmit.
"hg pull" has a "--remotecmd" option as well.
So you could pull one branch into the other one at home as well as
on the server.  Then merge local.  Then push the merged repository.

A code manager would be convenient, indeed.

I changed my mind.  We should use cvs-style branches.
They are really untidy and new, but I think more convenient to
the low bandwidth developers.  If we could forbid pushing and pulling
without specified tag, branch or revision  everything should work well.


I would like to store our graphics and sounds outside that repository.
Then we would be freer to change them without blowing our code
repository.

-- 
Kai Antweiler




reply via email to

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