On 23/10/2007, at 8:15 PM, Lapo Luchini wrote:
William Uther wrote:
I haven't removed the extra-commands.lua file. None of the
commands in
it will work at the moment. I'm not sure what to do here. If I
remove
it then I'll get bitten by die-die-die merge later - although I
guess I
William Uther wrote:
I thought I had such a warning in there... *looks* ... but I guess yours
is a little less cryptic than mine :) (and you have the pointer to the
branch)
Errr. ^_^'
You did, in fact.
It seems I was affected by one of my frequent cases of selective blindness.
Oh well, two
William Uther wrote:
I haven't removed the extra-commands.lua file. None of the commands in
it will work at the moment. I'm not sure what to do here. If I remove
it then I'll get bitten by die-die-die merge later - although I guess I
could just add it back without history. That might be
Resending to the list...
On 07/09/07, Zbynek Winkler [EMAIL PROTECTED] wrote:
On 07/09/07, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Again, please keep separate things separate. (And instead write simple
scripts for things like sync here, pull there, propagate a little and
then
Stephen Leake [EMAIL PROTECTED] wrote:
It probably would not hurt to restrict the code to POSIX sh. I think
you can tell Gnu bash to do that with a flag.
I have a soft-spot in my heart for GNU BASH, but such fodness only goes
so far when trying to write POSIX compatible script. BASH's
William Uther wrote:
On 06/09/2007, at 7:47 PM, Ulf Ochsenfahrt wrote:
Maybe monotone could do with a 'project' entity (policy branches?),
which collects multiple branches. Then you'd have a
net.venge.projects.eric project which would name all the branches you
are working on, and sync them
On Fri, Sep 07, 2007 at 11:48:12AM +0200, Koen Kooi wrote:
You mean posix sh scripts, right? Everytime you use a bashism god kills a
kitten.
Eventually the kittens will evolve and tear his eyes out.
Matthew
--
Matthew Sackman
http://www.wellquite.org/
William Uther [EMAIL PROTECTED] writes:
I'm happy with that. But I'd like the scripts to be cross platform.
Gnu bash scripts should be sufficiently cross-platform; they run on
all the platforms I'm aware of.
--
-- Stephe
___
Monotone-devel
Hi,
William Uther wrote:
Again, please keep separate things separate. (And instead write simple
scripts for things like sync here, pull there, propagate a little and
then update some of my workspaces.)
I'm happy with that. But I'd like the scripts to be cross platform. If
I'm supporting a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Leake schreef:
William Uther [EMAIL PROTECTED] writes:
I'm happy with that. But I'd like the scripts to be cross platform.
Gnu bash scripts should be sufficiently cross-platform; they run on
all the platforms I'm aware of.
You mean
Ulf Ochsenfahrt writes:
William Uther wrote:
On 06/09/2007, at 7:47 PM, Ulf Ochsenfahrt wrote:
Maybe monotone could do with a 'project' entity (policy branches?),
which collects multiple branches. Then you'd have a
net.venge.projects.eric project which would name all the
In message [EMAIL PROTECTED] on Wed, 05 Sep 2007 19:23:18 -0600, Derek
Scherger [EMAIL PROTECTED] said:
derek Ulf Ochsenfahrt wrote:
derek 6. give me an overview of what is new and exciting
derek
derek One of the things I've been wondering about lately is a more
derek informative type of
Hi,
William Uther wrote:
I was trying to think of the use case for update without a prior sync.
It seems that this is it: if you have lots of projects/branches in a
single database, then you might sync once and then need to update many
workspaces from the sync'd repository. You don't want
Eric Anderson wrote:
I'd be happy with this if the default was mtn pull default_host
current-branch, but the current setup which has the pull use the
first branch ever pulled doesn't work well if you're working on
multiple projects. I also wouldn't want it to do a mtn update unless
there are
On Thu, Sep 06, 2007 at 12:12:15PM +0200, Markus Schiltknecht wrote:
Again, please keep separate things separate. (And instead write simple
scripts for things like sync here, pull there, propagate a little and then
update some of my workspaces.)
Just to add my own 2p or 4c, I too think that
Derek Scherger schrieb:
Personally, I like the clean separation of pull/update and commit/push
even though I forget to update before starting something often enough.
Perhaps status should be telling all of us that newer revisions are
available and/or perhaps pull should be saying don't forget
On 06/09/2007, at 8:12 PM, Markus Schiltknecht wrote:
Hi,
Ulf Ochsenfahrt wrote:
(I'm also in favor of automatically updating the workspaces
afterwards.)
Why is that?
It's perfectly legal to keep workspaces around, which belong to an
old revision - ones which shouldn't be updated.
On 06/09/2007, at 7:47 PM, Ulf Ochsenfahrt wrote:
Maybe monotone could do with a 'project' entity (policy branches?),
which collects multiple branches. Then you'd have a
net.venge.projects.eric project which would name all the branches
you are working on, and sync them all in one go. (I'm
Richard Levitte wrote:
Not quite a ticker, but have you looked at
examples/display_branches.lua ?
I hadn't but I will!
Thanks,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Nathaniel Smith wrote:
The main concern people had was of plain 'mtn update' misbehaving when
people were offline -- hanging for a long timeout, blowing up, etc.
Not sure how much of a problem that would be in practice. One way to
find out would be to just enable it and see who screams :-).
I
On Wed, Sep 05, 2007 at 02:04:23PM +0200, Ulf Ochsenfahrt wrote:
Nathaniel Smith wrote:
The main concern people had was of plain 'mtn update' misbehaving when
people were offline -- hanging for a long timeout, blowing up, etc.
Not sure how much of a problem that would be in practice. One way
Nathaniel Smith wrote:
On Wed, Sep 05, 2007 at 02:04:23PM +0200, Ulf Ochsenfahrt wrote:
Nathaniel Smith wrote:
The main concern people had was of plain 'mtn update' misbehaving when
people were offline -- hanging for a long timeout, blowing up, etc.
Not sure how much of a problem that would be
Like Ulf, I too enjoy the simple separation between network and
non-network commands. I would be O.K. with changing the default
behavior to update iff I could over-ride that behavior via monotonerc.
i.e. Provide a generic way to specify default command-line options.
Hi,
Ulf Ochsenfahrt wrote:
For a sync *, monotone loads (almost) the entire database. (And
maybe this could be improved.)
(And this needs to be done on the client *and* on the server) Of course,
netsync can still be improved. And IMO absolutely *must* be improved
before even thinking about
Markus Schiltknecht wrote:
In my case, I certainly don't want to trigger a sync before each and
every update. Instead, something like at startup, then every 30 minutes
and before shutdown fits my workflow much better. And if you are now
thinking cronjob!, you've just stumbled across another
One of the reasons why I've switched over to monotone is that it
seperates very cleanly between network commands and non-network
commands.
Exactly! Please keep separate things separate. And KISS, instead of
trying to figure out automatically what the user wants.
In my case, I certainly
Ulf Ochsenfahrt wrote:
6. give me an overview of what is new and exciting
One of the things I've been wondering about lately is a more informative
type of ticker for netsync that would list branch/rev/author/date for
incoming and outgoing revisions.
Thinking about this now perhaps I should just
On Fri, Jul 06, 2007 at 10:40:18AM +0100, Bruce Stephens wrote:
Joel Crisp [EMAIL PROTECTED] writes:
Interesting, but how would you ensure that all distributed nodes had
the same version of the command scripts?
Policy branches?
Having different nodes with different collections of
On Fri, Jul 06, 2007 at 10:46:34AM +0200, Lapo Luchini wrote:
idea to me; there are indeed some command that I almost always execute
one after another, such as mtn sy ; mtn up (I began doing this after
the first 10 times I sync'ed and then happily worked and committed on
the old revision...).
On 04/09/2007, at 6:51 PM, Nathaniel Smith wrote:
On Fri, Jul 06, 2007 at 10:46:34AM +0200, Lapo Luchini wrote:
idea to me; there are indeed some command that I almost always
execute
one after another, such as mtn sy ; mtn up (I began doing this
after
the first 10 times I sync'ed and
On Tue, Sep 04, 2007 at 09:57:24PM +1000, William Uther wrote:
On 04/09/2007, at 6:51 PM, Nathaniel Smith wrote:
Everyone has this problem, i.e., this is a bug in 'mtn up'. Let's not
use extensibility as a way to plaster over problems in the core :-).
There was talk of adding a new option
William Uther wrote:
Any thoughts or suggestions?
While adding centralized-alike commands to mtn itself seems bad to me,
adding a generic LUA scriptable command engine to mtn seems like a GREAT
idea to me; there are indeed some command that I almost always execute
one after another, such as mtn
Joel Crisp [EMAIL PROTECTED] writes:
Interesting, but how would you ensure that all distributed nodes had
the same version of the command scripts?
Policy branches?
Having different nodes with different collections of extra commands is
surely an issue, but it's not one that seems to bother
If this works, it would also allow a general trigger mechanism a la
Clearcase etc
Joel
On 7/6/07, Bruce Stephens [EMAIL PROTECTED] wrote:
Joel Crisp [EMAIL PROTECTED] writes:
Interesting, but how would you ensure that all distributed nodes had
the same version of the command scripts?
34 matches
Mail list logo
