On 8/24/06, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
On Thu, Aug 24, 2006 at 10:06:48AM -0700, Justin Patrin wrote:
> If you really need to "split" a revision you can always make a
> checkout of the revision you want to split then revert all but 1 of
> the changes and check this in. Then repeat
On Thu, Aug 24, 2006 at 10:05:08PM -0600, Derek Scherger wrote:
> Marcel van der Boom wrote:
> >This currently allows me to quickly put a number of revisions in the
> >_MTN/revision file and get a feel where the workspace is at and what
> >needs to be done to upgrade/downgrade it to some revision
Marcel van der Boom wrote:
This currently allows me to quickly put a number of revisions in the
_MTN/revision file and get a feel where the workspace is at and what
needs to be done to upgrade/downgrade it to some revision we want.
Recently, the mtn pluck command has been added to the toolset f
On Thu, Aug 24, 2006 at 10:07:00PM -0500, Matthew Nicholson wrote:
> I like the idea of converting the signal handler into an exception in
> some safe manner. I am aware that you can't just throw an exception,
> and there is no straight forward way to do it that will work in every
> case, but t
On Thu, Aug 24, 2006 at 09:40:08AM +0100, Andy Jones wrote:
>I think the first half of the manual is the best discussion of version
>control that I have ever read. I mean that. A lightening bolt hit me,
>and I finally understood why I had this love/hate relationship with CVS.
>(Up
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 08:55:03PM -0500, Matthew Nicholson wrote:
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The te
On 8/24/06, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
binaries compiled with glibc 2.3, even
with the -static switch, still require glibc 2.3 be available to
fully work. It's _possible_ this isn't your problem -- the weird
not-quite-static issues only show up in certain cases. But it's
somethi
On Thu, Aug 24, 2006 at 10:06:48AM -0700, Justin Patrin wrote:
> If you really need to "split" a revision you can always make a
> checkout of the revision you want to split then revert all but 1 of
> the changes and check this in. Then repeat for all of the different
> things you want to split. Of
On Fri, Aug 25, 2006 at 09:27:21AM +1000, Daniel Carosone wrote:
> On Thu, Aug 24, 2006 at 01:22:28PM -0500, Chad Walstrom wrote:
> > According to Justin's comment, which I think is right on,
> > you need to back out the changes in B completely.
> >
> > mtn disapprove B
>
> Um, not what I
On Thu, Aug 24, 2006 at 09:13:12PM +0200, Detlef Vollmann wrote:
> Nathaniel Smith wrote:
> > On Thu, Aug 24, 2006 at 11:16:09AM +0200, Detlef Vollmann wrote:
> > > So I did:
> > > $ mtn --db=/source/monotone/snapshot/oe-060823.mtn checkout
> > > --branch=org.openembedded.dev
> > > --revision=c9f
On Thu, Aug 24, 2006 at 06:36:10PM +0100, Andy Jones wrote:
> I know it's a pain but really, ideally, this is a bug. Either the
> system should cope with multiple identical tags, or it shouldn't allow
> you to make them.Principal of least astonishment.
It does cope -- it says "there are multi
On Thu, Aug 24, 2006 at 03:24:18PM +0200, Markus Schiltknecht wrote:
> Nathaniel Smith wrote:
> >My memory of the discussion before is not that it was rejected for not
> >being like cvs2svn. Just, if you're making up your own algorithm,
> >we'd like to see a description and justification of it so
On Thu, Aug 24, 2006 at 08:55:03PM -0500, Matthew Nicholson wrote:
> Nathaniel Smith wrote:
> >On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
> >>Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
> >>on mtn log) fix pidfile cleanup? The test seems to stil
Nathaniel Smith wrote:
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
Umm, no... forgot about that :-).
It should be straightforwa
On Thu, Aug 24, 2006 at 06:49:37PM -0500, Matthew Nicholson wrote:
> Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
> on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
Umm, no... forgot about that :-).
It should be straightforward enough to come up w
On Thu, Aug 24, 2006 at 09:40:08AM +0100, Andy Jones wrote:
> And maybe, one more appendix? A glossary? Because no-one should need to
> understand the phrase "directed acyclic graph" to use Monotone...
This (and your other comments too, but specifically this as an
isolated item) is a really good
On Thu, Aug 24, 2006 at 12:30:06PM -0500, Chad Walstrom wrote:
> "Andy Jones" <[EMAIL PROTECTED]> wrote:
> > Alternatively I could just write a script that did 'mtn update -r t:test' !
> >
> > (Um, that +would+ get the +latest+ revision with that tag, right?)
>
> No. Tags are a different beast
On Thu, Aug 24, 2006 at 03:30:11PM +0100, Andy Jones wrote:
> Okay, only one more dumb question that I can think of: is there a doc
> somewhere that explains how the trust / quality assurance model works?
I added some pages to the wiki recently on just this subject (see a
recent mail), but haven'
Greetings,
Did the new signal handling stuff (to fix the delay/freeze after ctrl-c
on mtn log) fix pidfile cleanup? The test seems to still be an xfail.
--
Matthew Nicholson
matt-land.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
ht
On Thu, Aug 24, 2006 at 01:22:28PM -0500, Chad Walstrom wrote:
> So, if I'm following this correctly and referencing the DaggyFixes
> page, what we have here is something like this:
>
> A--B--C
>
> Where A is the buggy revision, and B is the revision containing the 5
> bug fixes.
Chad Walstrom wrote:
I don't think this would be possible. By the time you are inside the
editor to record your comment, monotone has already selected the files
to commit in the new revision. The best you could do is abort the
commit by comparing the log template before and after. If ther
"Andy Jones" <[EMAIL PROTECTED]> wrote:
> Oooh! People who use "dissaprove"! Keep talking. Do you use
> "approve" too? For what?
DaggyFixes wiki page explains it best. Essentially, all approve does
is assign a branch certificate to a revision. If the revision has a
common ancestor in the ne
On Wed, Aug 23, 2006 at 03:48:34PM -0700, [EMAIL PROTECTED] wrote:
> > Can anyone point me to a discussion on best practice using Monotone?
> Here's a start. Comments welcome. Somewhere on my todo list is to create a
> patch to the manual:
I dumped my earlier post, with some updates, into the
You're right - DaggyFixes covers all that. Sorry.
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrote:
"Andy Jones" <[EMAIL PROTECTED]> wrote:
> Oooh! People who use "dissaprove"! Keep talking. Do you use
> "approve" too? For what?
DaggyFixes wiki page explains it best. Essentially, all
Rob Schoening wrote:
As an enhancement to that, it would be equally useful to be able to
have an option to automatically include the diffs in the editor so
it's even easier to a) write changeset comments and b) double-check
that something isn't being erroneously included when it should really
Hmm. That's kind of counterintuitive, isn't it? "approve" and
"dissaprove" aren't mutually exclusive.
On 24/08/06, Andy Jones <[EMAIL PROTECTED]> wrote:
Oooh! People who use "dissaprove"! Keep talking. Do you use
"approve" too? For what?
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrot
Oooh! People who use "dissaprove"! Keep talking. Do you use
"approve" too? For what?
On 24/08/06, Chad Walstrom <[EMAIL PROTECTED]> wrote:
> mtn disapprove B
>
> This will "internally create a new revision with the reverse diff as a
> child of B". So we get,
^--- Should b
A suggestion to help prevent this from happening in the first place:
One feature that I've always wished for with CVS (and Monotone) is a slight bit more interactivity with the editor on commit.
Intuitively, I've always wanted to be able to exclude files from commit by simply deleting the app
"Rob Schoening" <[EMAIL PROTECTED]> wrote:
> Intuitively, I've always wanted to be able to exclude files from
> commit by simply deleting the appropriate CVS: or MTN: lines in the
> editor that correspond to the files that I want to exclude.
I don't think this would be possible. By the time you
Justin Patrin wrote:
> > yesterday I built monotone 0.29 (with problems) and tried to
>
> Well that's the first flag. What problems did you rbuild have?
Well, the first problem was my own: I had to build the new version
of boost and the install ran out of disk space, which I didn't
notice before d
Nathaniel Smith wrote:
> On Thu, Aug 24, 2006 at 11:16:09AM +0200, Detlef Vollmann wrote:
> > So I did:
> > $ mtn --db=/source/monotone/snapshot/oe-060823.mtn checkout
> > --branch=org.openembedded.dev
> > --revision=c9f0e213d8e0fdc01e39c1d5ebd4f3e5de4db6b1
> >
> > and this is the command that is
Exactly: multiple tags can't be prevented. And monotone does cope
with them. It's just that they don't work in quite the way you might
expect.
::grin:: you mean that it copes with them by raising an error? Must
be some strange new definition of "cope" that I was previously unaware
of...
Thin
> mtn disapprove B
>
> This will "internally create a new revision with the reverse diff as a
> child of B". So we get,
^--- Should be "A"
> A--B--C
> `--BR
--
Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/
ass
So, if I'm following this correctly and referencing the DaggyFixes
page, what we have here is something like this:
A--B--C
Where A is the buggy revision, and B is the revision containing the 5
bug fixes. According to Justin's comment, which I think is right on,
you need to back o
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
My point was: How would monotone know how to do such a thing? All of
I was just thinking of the same type of interface as the merge
interface, ie. with external tools. I have no clue how to do it, but
I just think it is an important work flo
I had meant to add the note about the Oedipus Rex merge, but forgot.
--Jack
> === Release Branch Pattern
...
> NOTES:
>
> - if one of the sub-branches added a file to a directory that was
> dropped in the 'example.com.foo.delivebles' branch, then you'll get a
> non me
"Andy Jones" <[EMAIL PROTECTED]> writes:
> I know it's a pain but really, ideally, this is a bug. Either the
> system should cope with multiple identical tags, or it shouldn't allow
> you to make them.Principal of least astonishment.
>
> I guess you would have to cope with them, since you can
On 8/24/06, Hugo Cornelis <[EMAIL PROTECTED]> wrote:
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
> Since each revision is one monolithic set of changes you would be
> better off checking in each of the things you want a s different
> revisionsas different revisions. You don't have to
I know it's a pain but really, ideally, this is a bug. Either the
system should cope with multiple identical tags, or it shouldn't allow
you to make them.Principal of least astonishment.
I guess you would have to cope with them, since you can't know that
you've currently got the whole univer
On 8/24/06, Justin Patrin <[EMAIL PROTECTED]> wrote:
Since each revision is one monolithic set of changes you would be
better off checking in each of the things you want a s different
revisionsas different revisions. You don't have to check in your
entire workspace. You can use restrictions t
"Andy Jones" <[EMAIL PROTECTED]> wrote:
> Alternatively I could just write a script that did 'mtn update -r t:test' !
>
> (Um, that +would+ get the +latest+ revision with that tag, right?)
No. Tags are a different beast in Monotone. They are not mobile, for
example. CVS's tag system was more
On 8/24/06, Hugo Cornelis <[EMAIL PROTECTED]> wrote:
I like the explanation about daggy fixes a lot
(http://venge.net/monotone/wiki/DaggyFixes). I think what is still
missing in the monotone command set is a command to split one
changeset in multiple changesets.
For example, if a changeset cont
On 8/24/06, Detlef Vollmann <[EMAIL PROTECTED]> wrote:
Hello,
yesterday I built monotone 0.29 (with problems) and tried to
Well that's the first flag. What problems did you rbuild have?
use it to check out a head from the OpenEmbedded database.
It checked out quite a lot of stuff, and then s
In message <[EMAIL PROTECTED]> on Thu, 24 Aug 2006 17:40:17 +0100, "Andy Jones"
<[EMAIL PROTECTED]> said:
andyjwork> Alternatively I could just write a script that did 'mtn update -r
t:test' !
andyjwork>
andyjwork> (Um, that +would+ get the +latest+ revision with that tag, right?)
No, if there
"Andy Jones" <[EMAIL PROTECTED]> writes:
> In CVS I had a permanent work area sticky on the tag "test". As each
> change was tested and passed by the QA team it got tagged. Then all I
> had to do was "cvs update" in the release area. The unit test version
> of the product ran from this working
In CVS I had a permanent work area sticky on the tag "test". As each
change was tested and passed by the QA team it got tagged. Then all I
had to do was "cvs update" in the release area. The unit test version
of the product ran from this working area, expected the code to be
there.
It seems to
I like the explanation about daggy fixes a lot
(http://venge.net/monotone/wiki/DaggyFixes). I think what is still
missing in the monotone command set is a command to split one
changeset in multiple changesets.
For example, if a changeset contains a bugfix and a new feature,
perhaps you only need
"Andy Jones" <[EMAIL PROTECTED]> writes:
[...]
> I couldn't say whether the current model was a good one or not. The
> testresult thing seems useful but not to me - in the language I use,
> the only thing you could do with it would be to check that the
> programs compiled, and any developer that
I read that a couple of days ago for the first time. I agree, it's first class. Any discussion of best practices has to include everything that it says.On 24/08/06,
Chad Walstrom <[EMAIL PROTECTED]> wrote:
Andy,The most powerful epiphany, or "Ah-ha!" moment, I had regardingmonotone was after rea
Andy,
The most powerful epiphany, or "Ah-ha!" moment, I had regarding
monotone was after reading:
http://venge.net/monotone/wiki/DaggyFixes
--
Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
_
Entirely at right angles to it, I'm afraid. But if it's not best practice to use it, I suppose that's all I need to know.I couldn't say whether the current model was a good one or not. The testresult thing seems useful but not to me - in the language I use, the only thing you could do with it wou
"Andy Jones" <[EMAIL PROTECTED]> writes:
> Okay, only one more dumb question that I can think of: is there a doc
> somewhere that explains how the trust / quality assurance model works?
Just the manual, I think.
And I don't think anyone really believes what's there works
particularly well (in t
Okay, only one more dumb question that I can think of: is there a doc somewhere that explains how the trust / quality assurance model works? The brief description in the manual takes things from a technical standpoint, rather than a functional one. I think I have a pretty good idea what the tool
Nathaniel Smith wrote:
My memory of the discussion before is not that it was rejected for not
being like cvs2svn. Just, if you're making up your own algorithm,
we'd like to see a description and justification of it so we have a
chance to apply some of the collective brain power here to making su
Andy Jones wrote:
This is brilliant, thanks.
Some stupid questions (the best kind):
Monotone doesn't care what branches are called, and you can rename
branches later on.
Err, how do you do that? You mentioned kill_branch_certs_locally...
http://www.venge.net/monotone/wiki/BranchRe
On Thu, Aug 24, 2006 at 11:16:09AM +0200, Detlef Vollmann wrote:
> What I did:
> download and unzip a snapshot
> $ mtn --db=/source/monotone/snapshot/oe-060823.mtn pull
> monotone.openembedded.org org.openembedded.dev
> mtn: successful exchange with monotone.openembedded.org
> $ mtn --db=/source/m
On Thu, Aug 24, 2006 at 11:48:14AM +0200, Markus Schiltknecht wrote:
> Markus Schiltknecht wrote:
> >I have read the design-notes.txt of cvs2svn (which is a very good
> >documentation of their process, BTW) and came to the conclusion that we
> >cannot rely on the timestamp of the file revisions.
Markus Schiltknecht wrote:
I have read the design-notes.txt of cvs2svn (which is a very good
documentation of their process, BTW) and came to the conclusion that we
cannot rely on the timestamp of the file revisions. Thus I began
implementing a file_id -> RCS revision number mapping. I've curre
Hi,
Nathaniel Smith wrote:
> There is a branch called .cvsimport-branch-reconstruction which
attempts to do this. It hasn't been merged or anything, because
everyone was too cowardly to figure out how it was supposed to work
and whether its approach was plausible or not :-(.
Yeah, and I'm st
This is brilliant, thanks.Some stupid questions (the best kind):
Monotone doesn't care what branches are called, and you can rename branches later on.Err, how do you do that? You mentioned kill_branch_certs_locally...
=== Vendor Branch Pattern So to my way of thinking we have vendor branches, wor
Hello,
yesterday I built monotone 0.29 (with problems) and tried to
use it to check out a head from the OpenEmbedded database.
It checked out quite a lot of stuff, and then seemingly
went into an endless loop: 100% CPU time and now more than
11 hours of CPU time, with no apparent action in the tar
Bruce Stephens wrote:
> Do "monotone certs ef736222cb8bd5af85eb593d850cb17872dabfc8" on the
> old database, and use the values to construct a selector, which you
> can then use on the new database.
>
> (Probably it'll be more than sufficient to use the branch, author, and
> date.)
Thanks, that wor
I think the first half of the manual is the best discussion of version control that I have ever read. I mean that. A lightening bolt hit me, and I finally understood why I had this love/hate relationship with CVS. (Up until that point I had honestly thought that version control was so complex a
63 matches
Mail list logo
