Markus Schiltknecht wrote:
Hello Lapo,
what's up with your buildfarm box? It seems to reproducibly segfault
during netsync. Any idea?
Mhh... it also seem to do it from normal command line use, using 0.36...
% mtn sy --debug
...
mtn: prepared statement SELECT data FROM revisions WHERE id = ?
Graydon Hoare wrote:
It probably does not require mentioning, but if possible of course I'd
encourage you to do this with a clean enough interface to monotone that
other projects can reuse it.
While I'm always pleased to have monotone be best at something,
extracting latent structure from a
I've merged net.venge.monotone.basic_io.inventory into
net.venge.monotone; see 07ae9cb7bea973d20cea3ff3db935744e66e9789.
I bumped interface_version in cmd_automate.cc to 6.0; this is a
backward-incompatible change.
--
-- Stephe
___
Monotone-devel
Michael Haggerty [EMAIL PROTECTED] writes:
[...]
(I've already made this offer [to cooperate in adding mtn support to
cvs2svn] to Markus Schiltknecht but he doesn't seem interested.)
I suspect because cvs2svn isn't incremental. So it's a way to do a
one-time conversion of a CVS repository,
revert_unchanged_file_preserves_mtime is failing intermittently on
Win32.
That is, most of the time it fails, but sometimes it passes.
This test is looking at file modification times; they should either
increase or not change.
The failure happens when they decrease.
From the test log, it looks
Michael Haggerty [EMAIL PROTECTED] writes:
[...]
cvs2svn added the unnecessary branch names because of a bug in
git-fast-import. I think that problem is fixed, but I haven't gotten
around to changing cvs2svn.
Ah, OK.
More interesting is whether the branches have to be created at all
for
Hello Michael,
sorry for not responding to your private mails earlier, I've been ill
the last few days.
Michael Haggerty wrote:
Graydon Hoare wrote:
It probably does not require mentioning, but if possible of course I'd
encourage you to do this with a clean enough interface to monotone that
Bruce Stephens wrote:
Michael Haggerty [EMAIL PROTECTED] writes:
[...]
(I've already made this offer [to cooperate in adding mtn support to
cvs2svn] to Markus Schiltknecht but he doesn't seem interested.)
I suspect because cvs2svn isn't incremental. So it's a way to do a
one-time
Hi,
Bruce Stephens wrote:
OK, that's probably worth doing. For repositories which include
imports, I suspect many of the tags will require a branch. I guess it
would depend on how one uses CVS tags as to whether it's often the
case that a branch is unnecessary. (At work we quite often (more
Patrick Georgi [EMAIL PROTECTED] writes:
[...]
There are a couple of invariants in the code that require revisions
to only have to ancestors. And I think some of the routines are
hardcoded for either one or two ancestors, too.
OK, I was misremembering.
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Right. For every tag and branchpoint which cannot be matched to
exactly only one revision, you'll have to add an artificial revisions
which you can tag. (AFAICT, git allows such an artificial revision to
have multiple parents, monotone does
Bruce Stephens schrieb:
I don't think monotone has such a restriction. I think it happens not
to create such revisions at present, but I don't think there's any
intrinsic requirement that a revision has at most two parents. I
imagine an importer from cvs2svn would use automate put_revision
Hi Bruce,
Bruce Stephens wrote:
I don't think monotone has such a restriction. I think it happens not
to create such revisions at present, but I don't think there's any
intrinsic requirement that a revision has at most two parents. I
imagine an importer from cvs2svn would use automate
On Mon, Sep 17, 2007, Thomas Moschny wrote:
Ralf S. Engelschall wrote:
Yes, I second that: --brief is really not the appropriate option name here.
Using --only-revs and then reverting my fix sounds reasonable.
Please go for it!
Done in 32f2e43b.., using --revs-only.
Thanks for your
Lately, every time I get a notification of spam on monotone-debian (in
the form of a moderator request), I go to the moderator page and it's
not there. Are people just deleting them before I get to them, or is
something glitched?
zw
___
On Tue, Sep 18, 2007 at 12:44:06PM +0200, Markus Schiltknecht wrote:
Right. For every tag and branchpoint which cannot be matched to exactly
only one revision, you'll have to add an artificial revisions which you
can tag. (AFAICT, git allows such an artificial revision to have
multiple
Hi,
Nathaniel Smith wrote:
Or just pick whichever single parent is the closest match, and write
out the tag as a child of that.
That would mean adding an artificial patch (from that closest match to
the tag revision you need) and an artificial revision (the one which you
are tagging). To
Oh - yeah then it becomes a missing directory if I take the easy way
out, and just rename the path...
On 9/18/07, J Decker [EMAIL PROTECTED] wrote:
I really really don't want to delete these files, I will very soon be
back to work in this space...
On 9/18/07, J Decker [EMAIL PROTECTED] wrote:
I really really don't want to delete these files, I will very soon be
back to work in this space...
On 9/18/07, J Decker [EMAIL PROTECTED] wrote:
mtn.EXE: switching to branch com.fortunet.altanik
mtn.EXE: warning: cannot drop non-empty directory
'src/fut/flashdrive/flashdrivetester'
mtn.EXE:
mtn.EXE: switching to branch com.fortunet.altanik
mtn.EXE: warning: cannot drop non-empty directory
'src/fut/flashdrive/flashdrivetester'
mtn.EXE: misuse: 1 workspace conflicts
this is caused by creating a project with sources and building it,
which created objects and sub-directories in the
On 19/09/2007, at 9:39 AM, J Decker wrote:
I really really don't want to delete these files, I will very soon be
back to work in this space...
On 9/18/07, J Decker [EMAIL PROTECTED] wrote:
mtn.EXE: switching to branch com.fortunet.altanik
mtn.EXE: warning: cannot drop non-empty directory
William Uther spake unto us the following wisdom:
Hrm - if the files are auto-generated, then you should just delete
them. You can re-generate them when you update back to this revision
again. But you say you don't want to do that, so I assume that they
have original data. In which
Ethan Blanton spake unto us the following wisdom:
There is another possibility -- maybe they are simply expensive to
generate. Several times in renaming directories in the Pidgin source
tree, I've had to blow away quantities of object files which I would
rather have kept, all things being
On 19/09/2007, at 12:51 PM, Ethan Blanton wrote:
William Uther spake unto us the following wisdom:
Hrm - if the files are auto-generated, then you should just delete
them. You can re-generate them when you update back to this revision
again. But you say you don't want to do that, so I
On 9/18/07, William Uther [EMAIL PROTECTED] wrote:
I'm not sure this makes a real difference. Either you want to re-
generate them or you don't. If you don't want to re-generate them
then you should add them.
I have nothing in particular to add to the rest of the discussion, but
I want to
25 matches
Mail list logo
