>> Project manager: uhmmm, ideas?
>
> That could be up to the project manager, and he could require his users
> to include it. But that wouldn't work, because one user could very well
> work on multiple projects. Perhaps is could hide in the _MTN directory.
_MTN/monotonerc is already checked per
On Thu, Jun 16, 2011 at 06:20:53PM +0200, Richard Levitte wrote:
> In message <20110616124052.ga12...@topoi.pooq.com> on Thu, 16 Jun 2011
> 08:40:52 -0400, Hendrik Boom said:
>
> hendrik> On Thu, Jun 16, 2011 at 09:38:36AM +0100, CooSoft Support wrote:
> hendrik> > Nuno Lucas wrote:
> [...]
> he
In message <20110616124052.ga12...@topoi.pooq.com> on Thu, 16 Jun 2011 08:40:52
-0400, Hendrik Boom said:
hendrik> On Thu, Jun 16, 2011 at 09:38:36AM +0100, CooSoft Support wrote:
hendrik> > Nuno Lucas wrote:
[...]
hendrik> > 1) Yes the documentation, which I think is very good btw, needs to
ma
On Thu, Jun 16, 2011 at 09:38:36AM +0100, CooSoft Support wrote:
> Nuno Lucas wrote:
>> Hello,
>>
>> On Mon, Jun 13, 2011 at 00:14, Stephen Leake
>> wrote:
>>
>>> Hendrik Boom writes:
>>>
So my real problem was not knowing about the approve command. I may
have heard about it be
Nuno Lucas wrote:
Hello,
On Mon, Jun 13, 2011 at 00:14, Stephen Leake
wrote:
Hendrik Boom writes:
So my real problem was not knowing about the approve command. I may
have heard about it before, but if I did assumed it was for reporting on
the success of testing, rather than providin
On Mon, Jun 13, 2011 at 01:43:06AM +0100, Nuno Lucas wrote:
>
> The decision to branch is done mostly a long time before the real
> commit, so there is a good chance to forget about it at commit time.
> Doing "dummy" commits or manually editing the _MTN/options file feels "dirty".
I had thought o
Hello,
On Mon, Jun 13, 2011 at 00:14, Stephen Leake
wrote:
> Hendrik Boom writes:
>> So my real problem was not knowing about the approve command. I may
>> have heard about it before, but if I did assumed it was for reporting on
>> the success of testing, rather than providing a branch name.
>
Hendrik Boom writes:
> On Sun, Jun 12, 2011 at 04:44:24PM +0200, Thomas Keller wrote:
>>
>> Not yet unfortunately, but it would be easy to let it load
>> /etc/monotonerc or something similar by default (we could make the
>> actual path configurable at build time). The interesting part here is
>>
Hendrik Boom writes:
> So my real problem was not knowing about the approve command. I may
> have heard about it before, but if I did assumed it was for reporting on
> the success of testing, rather than providing a branch name.
Hmm. I would have thought so, too. But that's not what the manua
On Sun, Jun 12, 2011 at 04:44:24PM +0200, Thomas Keller wrote:
>
> Not yet unfortunately, but it would be easy to let it load
> /etc/monotonerc or something similar by default (we could make the
> actual path configurable at build time). The interesting part here is
> src/lua_hooks.cc, lines 256ff
On Sun, Jun 12, 2011 at 04:24:35AM -0400, Stephen Leake wrote:
> Richard Levitte writes:
>
> > In message <4df22cfb.60...@thomaskeller.biz> on Fri, 10 Jun 2011 16:40:59
> > +0200, Thomas Keller said:
> >
> > me> Am 10.06.2011 16:26, schrieb Hendrik Boom:
> > me> > Actually, the approve command
On Sun, Jun 12, 2011 at 17:13, Stephen Leake
wrote:
> What would the equivalent path on Windows be? The equivalent of
> ~/.monotone/monotonerc is
>
> c:/Documents and Settings/Stephe Leake/Application Data/monotone/monotonerc
>
> so I guess /etc/monotonerc would be
>
> c:/Documents and Settings/Al
CooSoft Support writes:
>One thought I had is that it would be nice to have the ability to
> specify a site wide/system wide LUA file so that you could set it up
> in one place and all users would by default pick it up. Rather like
> Emacs's site.el file.
I do that by putting
dofile("/
Am 12.06.11 15:13, schrieb CooSoft Support:
>One thought I had is that it would be nice to have the ability to
> specify a site wide/system wide LUA file so that you could set it up in
> one place and all users would by default pick it up. Rather like Emacs's
> site.el file. Or can one do that
> How do other DVCs handle this? git, mercury?
git: "git checkout -b " will do the equivalent of adding a
cert and adjusting _MTN/options. "git branch " will do the
equivalent of just adding a cert, leading _MTN/options unchanged.
--
Jerome Baum
tel +49-1578-8434336
email jer...@jeromebaum.com
w
I quite agree with the `support the workflow via lua' approach
below. Mtn provides what you need and the interface is currently clean
and simple.
One thought I had is that it would be nice to have the ability to
specify a site wide/system wide LUA file so that you could set it up in
one
Richard Levitte writes:
> However, as far as I understand, Hendrik really just wants the next
> commit to end up in the new branch. The simplest way to do that is to
> edit the branch setting in _MTN/options... I really think we should
> have a 'mtn branch' that does exactly that. Last time I
Hendrik Boom writes:
> On Thu, Jun 09, 2011 at 08:46:40PM +0200, Thomas Keller wrote:
>> Am 09.06.11 20:14, schrieb Hendrik Boom:
>> > I checked out a new workspace, and I want to check it in again unchenged
>> > with a new branch name -- the one I want to use to make changes. I'd
>> > like t
Richard Levitte writes:
> In message <4df22cfb.60...@thomaskeller.biz> on Fri, 10 Jun 2011 16:40:59
> +0200, Thomas Keller said:
>
> me> Am 10.06.2011 16:26, schrieb Hendrik Boom:
> me> > Actually, the approve command worked fine, though it took a few moments
> me> > to determine the right rev
We use the `mtn cert branch... mtn update to new branch' approach on our
project at work. All changes are done on their own branch and we felt
that setting up the new branch beforehand would be far less likely to
cause problems (only approved work would be started). We felt that
hoping a dev wo
In message <4df22cfb.60...@thomaskeller.biz> on Fri, 10 Jun 2011 16:40:59
+0200, Thomas Keller said:
me> Am 10.06.2011 16:26, schrieb Hendrik Boom:
me> > Actually, the approve command worked fine, though it took a few moments
me> > to determine the right revision ID. Maybe approving the revisi
On Fri, Jun 10, 2011 at 04:40:59PM +0200, Thomas Keller wrote:
> Am 10.06.2011 16:26, schrieb Hendrik Boom:
> > Actually, the approve command worked fine, though it took a few moments
> > to determine the right revision ID. Maybe approving the revision in the
> > current workspace should be an o
Am 10.06.2011 16:26, schrieb Hendrik Boom:
> Actually, the approve command worked fine, though it took a few moments
> to determine the right revision ID. Maybe approving the revision in the
> current workspace should be an option on that command? I wouldn't want
> it to be the default: too ea
On Fri, Jun 10, 2011 at 07:03:55AM -0700, Stephen Leake wrote:
> Quoting Hendrik Boom :
>
>> On Thu, Jun 09, 2011 at 02:14:16PM -0400, Hendrik Boom wrote,
>>
>> but forgot to mention he was using mtn 1.0:
>>
>>> I checked out a new workspace, and I want to check it in again unchenged
>>> with a new
Quoting Hendrik Boom :
On Thu, Jun 09, 2011 at 02:14:16PM -0400, Hendrik Boom wrote,
but forgot to mention he was using mtn 1.0:
I checked out a new workspace, and I want to check it in again unchenged
with a new branch name -- the one I want to use to make changes. I'd
like to make it clea
On Thu, Jun 09, 2011 at 08:46:40PM +0200, Thomas Keller wrote:
> Am 09.06.11 20:14, schrieb Hendrik Boom:
> > I checked out a new workspace, and I want to check it in again unchenged
> > with a new branch name -- the one I want to use to make changes. I'd
> > like to make it clear that the new
Am 09.06.11 20:14, schrieb Hendrik Boom:
> I checked out a new workspace, and I want to check it in again unchenged
> with a new branch name -- the one I want to use to make changes. I'd
> like to make it clear that the new branch is starting in the same state
> as the current head in the old
On Thu, Jun 09, 2011 at 02:14:16PM -0400, Hendrik Boom wrote,
but forgot to mention he was using mtn 1.0:
> I checked out a new workspace, and I want to check it in again unchenged
> with a new branch name -- the one I want to use to make changes. I'd
> like to make it clear that the new bran
I checked out a new workspace, and I want to check it in again unchenged
with a new branch name -- the one I want to use to make changes. I'd
like to make it clear that the new branch is starting in the same state
as the current head in the old one.
But when I try to check in, it fails:
hend
29 matches
Mail list logo
