-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hend...@topoi.pooq.com schrieb:
On Thu, Apr 16, 2009 at 09:29:21PM +0200, Christof Petig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hend...@topoi.pooq.com schrieb:
Among the three branches I found, namely,
net.venge.monotone.cvssync
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Leake schrieb:
That would be named pipes, and they are sufficiently different from
unix sockets that things break; that's why file: and ssh: are not
supported on Windows.
Some months ago I spent several days making sure that file and ssh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
Hi,
Christof Petig wrote:
The problem at hand is the malloc and memset overhead introduced by
using a dynamic buffer.
Huh? Why do we use memset there? malloc() hardly makes for a 40%
speedup, does it?
Botan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
Hi,
Christof Petig wrote:
just some notes for myself on the performance problems with OE:
- - hex_decode is used extensively by roster.cc: parse_marking (and
expensive)
- - get_roster_version is taking 90
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
mtn: Zertifikate | Schlüssel | Revisionen
mtn: 76.702 |74 | 25.283
mtn: Bytes rein | Bytes raus | Zertifikate rein | Revisionen rein
mtn: 1,1 M |361,4 k | 560/560 | 136/136
mtn: erfolgreicher Austausch mit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
Hi,
Christof Petig wrote:
I tested Thursday's net.venge.monotone with binary ids and I don't know
about cached pipes. But this should be easy to speed up (especially
given that, according to Lapo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Thomas Keller schrieb:
Holger Freyther schrieb:
I'm feeling blind with monotone:
- git-rev-list origin/qtwebkit.. (to show what I would push now) is
missing
- gitk is almost instantly working on the OE tree
- git-fetch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
just some notes for myself on the performance problems with OE:
- - hex_decode is used extensively by roster.cc: parse_marking (and
expensive)
- - get_roster_version is taking 90% of the time
- - hex_decode is taking 25% of the time
- - hex_encode is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Patrin schrieb:
It seems that some of the folks at OpenEmbedded are now grumbling
about use of monotone again and that some of our key developers are
looking to switch to something else (hg or git)[1]. The main point of
contention seems to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zack Weinberg schrieb:
On Thu, Mar 13, 2008 at 11:51 AM, Koen Kooi
[EMAIL PROTECTED] wrote:
Markus Schiltknecht schreef:
| Koen Kooi wrote:
| As the subject already hints at, OpenEmbedded is seriously looking at hg
| and git because mtn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
Hi all,
Again, this is probably most relevant to Christof Petig... I've just
committed a test to the n.v.m.cvssync.refactor branch that causes a
freeze in mtn_cvs pull. The test is skipped just before the line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chad Walstrom schrieb:
William Uther [EMAIL PROTECTED] wrote:
Hi all,
On the weekend I made a new branch: net.venge.monotone.cvssync.attrs
What happened to Christof Petig's rewrite #3?
http://www.venge.net/mtn-wiki/CvsSync3
Simple:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Brenta schrieb:
mtn_cvs: warning: cvs [rlog aborted]: could not chdir to internal:
Permission denied
mtn_cvs: error: log failed
Is there a way for mtn_cvs to just ignore directories like internal,
and carry on with the rest of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
Hi,
I've just been trying out a recent revision of n.v.m.cvssync.refactor.
(4a94d2a8a0f2daf32daad76900ecb9fb4c5a0f331)
It looks good and passes the tests. Thank you. :)
Questions and comments:
Is this at a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
I planned to get full history mtn2cvs-export working tonight (?).
This is export from mtn to cvs? We already have 'push', right? So this
is for exporting to new CVS repositories?
Correct. Tonight seems to be too
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
iv) A normal subversion server has a fixed directory layout with
branches/, tags/ and trunk/. If you link with the svn libraries,
then you could use them to access the server, add another directory
there, mtn/. That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
State:
- - cvssync1: finished, tested, slow
- - cvssync3: work in progress, did work before the summit, needs a bit
more work to compile again, passes test cases but I saw some strange
issues
- - cvssync4: proposed by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Uther schrieb:
There seem to be two options:
i) the net.venge.monotone.cvssync branch. (Or the
net.venge.monotone.cvssync.refactor branch?)
What state is this in? I couldn't find much documentation for it, and
what I could find
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christof Petig schrieb:
I will put some work into cvssync3 tonight, stay tuned.
I'm not finished yet, but I will continue tomorrow.
Christof
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
http://www.venge.net/monotone/wiki/MultiParentWorkspaceFallout on the
wiki currently states: A revision can't have more than two parents.
While Graydon recently answered me, that monotone itself does not pose
such a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nathaniel,
please take some time to take a second look at the current head of the
nvm.cvssync branch, I implemented your suggestions and will continue on
the other side of the pipe ;-)
Christof
-BEGIN PGP SIGNATURE-
Version: GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schrieb:
After a somewhat adventurous trip from the airport to the hotel, we now
realized that, back in Europe people are just about to get up again. We
are all quite tired, but really looking forward to a great week!
Fast
Zack Weinberg schrieb:
It occurred to me that we store a lot of SHA1 hashes in our databases
and they're all twice as big as they need to be because they're in
hex.
I added a project like this to the summit projects and really second the
move (I coded the base64-binary move in the past).
I'm
Christof Petig schrieb:
PS: I _shall_ not need funding for the summit. IMHO if fully apprenticed
university engineers with a paid job ask for funding something is going
wrong indead. OTOH paying the flight just because of a hobby hurts my
family's holiday budget, too.
Please do not get me
Christof Petig schrieb:
Please do not get me wrong: I was explaining why I could not honestly
ask for funding, I was not intending to say that engineers should not
need funding.
It's difficult to get sensitive stuff non ambiguously: please insert in
general after engineers.
Christof
Hi,
I separated the less controversial automate extensions of cvssync3 into
the branch net.venge.monotone.cvssync.candidates .
Can you take a look whether these are fitting into mainline?
(Documentation is added, a ChangeLog isn't yet)
Namely they are:
db_get domain varname
db_set domain
Hi,
here's the second part of my automate proposals:
How do you feel about adding an automate command to query the current
workspace (e.g. branch, root dir, default key, database location etc.).
These values are located inside .../_MTN/options and I don't want to
write yet another routine to
Thomas Keller schrieb:
Christof Petig schrieb:
What about
$ mtn automate get_workspace
database /usr/local/lib/monotone.db
branch net.venge.monotone.cvssync.refactor
keydir /home/christof/.monotone/keys
key [EMAIL PROTECTED]
workspace /home/christof/projects/monotone
mtn
Thomas Keller schrieb:
put_file [base-id] contents
put_revision changeset
What is put_revision's format? Is this something which could be
tweaked/used to let monotone understand its own diff format (the header
of that is a changeset, I believe)?
I wanted to implement it least invasive
Ben Walton schrieb:
I have a mostly completed set_option that might meet this need. I
hadn't placed it in the automate group of functions, but rather the
general workspace set. Would it be better placed in automate?
I guess so. Since many frontends exclusively use automate stdio a
different
Hi Nathaniel,
Nathaniel J. Smith schrieb:
-lookahead = *curr;
+lookahead = *curr 0xff;
Using:
lookahead = widenint,char(*curr);
is better (I guess maybe with a comment? this is exactly the sort of
situation widen is designed for, though), and this patch appears to
use tabs
Nathaniel J. Smith schrieb:
On Wed, Dec 06, 2006 at 06:31:32PM +0100, Christof Petig wrote:
Hi,
within mtn_cvs I transfer binary (gzip'd) data between mtn and mtn_cvs
using basic_io. I found that NUL bytes terminate a lexical unit (if
that's the exact wording) and so the parser aborts
Hi,
within mtn_cvs I transfer binary (gzip'd) data between mtn and mtn_cvs
using basic_io. I found that NUL bytes terminate a lexical unit (if
that's the exact wording) and so the parser aborts with an error.
Should I
- fix basic_io to work with NUL bytes, or
- escape NUL bytes (e.g. as \0 )
, CC'ing me
directly gives a higher probability of a timely answer.
Right, there Christof Petig has written in cvs_mtn/CVS_prot, at the very
bottom:
=== attributes ==
cvs:root cvs.gnome.org:/cvs/gnome (Root)
cvs:module glade-- (?Repository)
[ cvs:path glade-- (only
Hi,
I just wanted to share this piece of code with you:
it will assume that every pre-roster and non-utf8 filename is actually
latin1 encoded and fix it.
Useful if rosterify gives you errors about non-utf-8-file names.
Christof
Markus Schiltknecht schrieb:
I've been thinking about how to store additional information for a
revision which got imported from another VCS (i.e. as cvs_import does).
As certs are not stored and transmitted efficiently enough, it has been
proposed to store such information in attributes.
Thomas Moschny schrieb:
On Sunday 03 December 2006 18:45, Markus Schiltknecht wrote:
As certs are not stored and transmitted efficiently enough [...]
Can you elaborate a bit on that? What's the problem with certs? They are
key-value pairs attached to revisions, so - exactly what you want.
Hi,
while I implemented the attribute storage of cvssync I noticed that the
following command does not work:
$ mtn attr set / test 42
mtn: misuse: absolute path '/' is invalid
(neither does set test 42 work)
So my questions are:
Should we make an exception for / as a valid path name for an
Thomas Keller schrieb:
Try (in the root dir)
$ mtn attr set . test 42
I've voted to name the root directory / or something different, but
this hasn't happened until now.
Thank you!
I just looked at what was written in the revision file and what
monotone-viz showed me.
I'm perfectly
Ethan Blanton schrieb:
Christof Petig spake unto us the following wisdom:
- a cvs server process against a monotone database (if there's _any_
benefit)
This is an interesting suggestion; I assume you mean a monotone
server process which serves (perhaps read-only) to a generic cvs
client
Thomas Keller schrieb:
Dirk Hillbrecht schrieb:
Well, it says: ..and we might see whether I can host you.. So, Dirk,
what does that include? Office rooms with WLAN? A place to sleep?
I can offer office rooms in the city center of Hannover (5 min by foot
from main station) with LAN (2 MBit/s
Ulf Ochsenfahrt schrieb:
Theres, three times Wuppertal, once Berlin, once Rostock, once Lübeck.
Three times? Ups. That looks like it's an European center of monotone
development :-)
And it sounds like we should be able to meet in person just for an
evening any time we like. I'd happily invite
Graydon Hoare schrieb:
I was wondering if you could point me to (or provide) a brief
description of the work you've been doing on cvssync recently, what it
does, and what its status is. Interoperating with other VC tools is one
of the things I'd like to get a handle on eventually.
I've
Ulf Ochsenfahrt schrieb:
The monotone serve command crashes when the connection times out.
Not good.
To even start thinking about this bug we would at least need the output
of mtn --full-version which indicates operating system, monotone version
and the like.
mtn: fatal: std::runtime_error:
Nathaniel Smith schrieb:
- a user imports a changed cvs working directory into monotone and works
from that. I need a mechanism to remember which files were already
changed at that point (by inserting an invalid (or missing?) file_id)
Hmm, wouldn't the right way to do this be to import the
Nathaniel Smith schrieb:
They are pretty efficient -- most importantly, revisions only describe
changes in attributes, and they are stored inside the roster, which is
already delta-compressed as a whole. I can't think of any reason why
this would be noticeably less efficient than putting the
Nathaniel Smith schrieb:
Proposal:
attributes cvs-revision 1.2
[cvs-keyword-expansion -kb] (-kk is standard like in CVS?)
Should be either cvs:revision or mtn:cvs-revision, following the
namespace:name convention. It looks like cvs2svn uses
cvs2svn:cvs-revnum, which doesn't strike me
Daniel Carosone schrieb:
On Thu, Sep 07, 2006 at 07:55:06PM +0200, Christof Petig wrote:
Proposal:
attributes cvs-revision 1.2
[cvs-keyword-expansion -kb] (-kk is standard like in CVS?)
looks fine. (is it really rcs-revision?)
yes it is rcs-revision but cvs:rcs-revision sounds ugly
Markus Schiltknecht schrieb:
Heh, cool. You mean, file attributes are stored in the manifest... can I
store 'revision attributes' there? Like the ones in sample I mentioned:
CVS_server_path :pserver:[EMAIL PROTECTED]:/foo/cvsroot
that's the root, isn't it. The server path is in the file
Nathaniel Smith schrieb:
So maybe what we need is a better
articulation of what this tri-state helps with?
Side note: I also need a file_id tristate for cvssync (in
.mtn-sync-cvs). Perhaps even more people have a need for invalid/fake ids.
[The meaning in cvssync is: The ID of the synced file
Daniel Carosone schrieb:
You need to know this, but do you actually need to store this
explicitly? If you set an attr in revision N at sync time to the cvs
id, and then in a child revision M there's a local commit that changes
content, you can see this from the rosters of M and N where there
Graydon Hoare schrieb:
Anyways, I wonder how much everyone here really feels it's an important
thing to do overall. Is venge.net/monotone (or say, mtn.venge.net)
unacceptable?
I'm perfectly happy with mtn.venge.net
Christof
signature.asc
Description: OpenPGP digital signature
1. mtn.venge.net
2. monotone-vcs.org
3. mtn-vcs.org
4. monoto.ne (innovative though strange, sounds japanese or one of the
many african languages)
I don't see any additional benefit of monotone.ca/it over
monotone.venge.net.
scm ??? (starts wikipedia and gets lost:
Markus Schiltknecht schrieb:
If we store the original RCS version as a file attribute, how can the
end-user query what CVS files he got with a given MTN revision? Where
could we save 'per revision' information? (The 'all CVS commits were
between 27/08/2006 15:42:13 and 27/08/2006 15:42:19' or
Lapo Luchini schrieb:
file_id 03cfd743661f07975fa2f1220c5194cbaff48451
is ::ext::[EMAIL PROTECTED]:/usr/local/cvsroot's module/subdir/A 1.17.0.5
and .../A 1.18
and .../B 1.2
But file attributes are revision-specific, they aren't on the fild_id,
are they?
(attributes as in mtn attr
Nathaniel Smith schrieb:
On Sun, Aug 27, 2006 at 12:07:33AM +0200, Christof Petig wrote:
The main reason for me to use a special file format is to have the
information in one place (which also applies to attributes) and to base
some logic upon whether this file was changed since the last
Markus Schiltknecht schrieb:
cvssync2 adds a file (called .mtn-sync-cvs which contains (more than) a
table of ( revision[/keyword_substitution] path file_id ) per revision
to store that information (easily delta encoded and distributed this
way)).*
I would be happy to have any rcs_revision
Daniel Carosone schrieb:
On Wed, Aug 23, 2006 at 08:47:55PM +0200, Lapo Luchini wrote:
cvssync and cvs_import do not mix (yet) since cvs_import does not
remember the corresponding cvs revisions for each file.
I think adding a certificate with the corresponding CVS revision would
be a *good
Nathaniel Smith schrieb:
On Fri, Aug 25, 2006 at 09:18:01AM +0200, Christof Petig wrote:
cvssync2 adds a file (called .mtn-sync-cvs which contains (more than) a
table of ( revision[/keyword_substitution] path file_id ) per revision
to store that information (easily delta encoded
Christof Petig schrieb:
I have to change the synchronisation information on push (monotone
commits into CVS) and I cannot change the contents of files of an
existing information. Thus I wanted to avoid a mechanism which looks to
that should have read existing revision
signature.asc
Lapo Luchini schrieb:
Use case: as some of my latest messages may have lead to think, I'd like
to mtn cvs_import the full FreeBSD /src CVSROOT.
du -h reports 1.8 GiB worth of CVS ,v files that cvs_import imports
in a database around 1 GiB in size (my import created a 500+ MiB one and
a 80 MiB
Tony Tung schrieb:
On Aug 4, 2006, at 7:15 PM, Nathaniel Smith wrote:
On Fri, Aug 04, 2006 at 05:42:17PM -0700, Tony Tung wrote:
Any thoughts on how to indicate a branch collapse in the database?
As I understand it, the predecessors' hash is part of the computation
of the revision hash.
Timothy Brownawell schrieb:
*) The information attachment is meant to be space efficient (xdiff
encoded where possible) and uses both special files .mtn-syn-* and
certificates where it has to attach information to an already present
revision.
Why is there a need for this? It seems like it
Koen Kooi schrieb:
Could this be used to setup up a read-only SVN/CVS mirror for an
existing monotone project?
yes and no ...
you can not map monotone's meshed ancestry onto a linear path. So you
can only export a linear subgraph of each branch. Multiple heads within
one branch are only common
Hi,
as announce earlier this year I worked on separating the cvs
synchronisation from monotone core. The core part is mainly done (and my
custom binary which uses sanity.h, ui.h, cmd.h etc. actually compiles,
runs and parses its options).
The following additional automate commands are part of
Daniel THOMPSON wrote:
My revision of CVS 1.11.21 (Fedora RPM revision -3.2) has taken to
embedding the port number in the CVSROOT in a manner that monotone's
cvssync code does not comprehend.
Basically CVSROOT looks like this:
:pserver:[EMAIL PROTECTED]:2401/home/repository
The current
Graydon Hoare wrote:
Christof Petig wrote:
P3S: Expect me to _try_ to get some automate extensions into monotone to
use with cvssync. And expect me to ask again for integrating the
non-blocking-pipe-abstraction (win32) from nvm.cvssync.win32 .
I have every intention of trying to get
Nathaniel Smith wrote:
In this issue of your monotone electronic newsletter, we direct your
intention to an innocent looking file named server.pl, available by
running
git clone http://mirrors.catalyst.net.nz/git/gitcvs.git/
on your internet-enabled posixish box.
With this script, you
Timothy Brownawell wrote:
It's not mentioned anywhere because it doesn't really work (yet). It
compiles and runs, but tends to hang whenever it has to talk to the
My experiences so far are:
- browse the workspace (diff, contents, unknown files etc): no hang
- add a file: monotone hangs
Nathaniel Smith wrote:
Right, my apologies yet again for taking so long to get back to this,
just trying to catch up on things again. This branch has been more
trouble than it really should have been, mostly my fault... but I
think we're almost there!
Thank you for keeping up the work on
Hi Timothy,
do you currently plan to port mtsh to windows? I might be able to get
fund to do the port but wanted to ask you first.
I already wrote a pipe+exec+fork (bidirectional asynchronous pipe)
equivalent for the nvm.cvssync.win32 branch, so it's mainly a matter of
adapting mtsh to it (and I
Christof Petig wrote:
Hi Timothy,
do you currently plan to port mtsh to windows? I might be able to get
fund to do the port but wanted to ask you first.
I already wrote a pipe+exec+fork (bidirectional asynchronous pipe)
equivalent for the nvm.cvssync.win32 branch, so it's mainly a matter
Vinzenz 'evilissimo' Feenstra wrote:
Christof Petig schrieb:
I will do it right now, so don't bother to do it at the same time.
Christof
Oh that's good. I was getting crazy while trying it *g*
Trying to resolve the conflicts was not easy (I knew what you did but my
std::vector change
Jeronimo Pellegrini wrote:
Hello.
I've been using monotone for several months now (and I'm quite happy
with it), and there's one thing that I would like to suggest:
Since I keep several copies of a database in different places (laptop,
desktop, USB stick, etc), I usually want to sync them
Nathaniel Smith wrote:
Christof, I'm sorry -- this is probably going to cause a bunch of
annoying conflicts for the .binary branch :-/. Probably it should
have just been done on that branch, but we've gone round and round on
it so many times that I decided it was time to just get something
Vinzenz 'evilissimo' Feenstra wrote:
I've tested the modifications now and corrected them. The source
compiles fine now.
So this should be the final diff for it :)
What a mess ...
If I compare the patch to the subject of this thread I feel a bit sick.
While Nathaniel stated that std::string,
Vinzenz 'evilissimo' Feenstra wrote:
We talked about it this night and decided not to give up the va_args.
Instead we're using a struct now which helps us to identify the value.
So we can now use SQLITE_STATIC as argument for sqlite3_bind_text and
sqlite3_bind_blob and can figure out in the
Hi,
I finished the first part (base64-BLOB) of migrating the database
layout to use BLOBs and am very pleased with the results:
## - ##
## Test results. ##
## - ##
All 298 tests behaved as expected.
PASS: ./testsuite
==
All 2 tests passed
Conrad Steenberg schrieb:
Just out of curiosity, do you notice speed improvements as well as the
obvious size reduction?
Of course all disk bound activity is speed up by a factor of 33% as well
(you have to transfer much less data) and to me monotone is mostly disk
bound. But since the cert
Last month Daniel Carosone proposed to store the corresponding CVS
revisions for a given (imported or cvssynced) monotone revision within
the usual files: */CVS/Entries, */CVS/Repository instead of using a
hidden file (like .mt-cvs_revisions).
I see some drawbacks and some benefits, what do you
Nathaniel Smith schrieb:
On the other hand, I don't see why cvs_import and cvssync couldn't
record what they've done in a compatible format, so that you can do a
cvs_import and then use the resulting repo with cvssync, for
instance...
cvs_import would have to generate certificates which
Markus Schiltknecht schrieb:
Right now we just do things in memory, and it seems to go okay. We'd
have to look at the argument for how saving stuff somewhere persistent
would be a significant win, I guess.
I was thinking about helping re-import. A re-import could use
information like what
[CCing the list]
Markus Schiltknecht schrieb:
What do you think?
A totally different approach would be to enhance the cvssync branch to
replace cvs_import. It can import local and remote repositories alike.
And you can reimport/commit changes from/to the server. My basic feeling
is that
Hi,
while the other developers are busy exploring rosters I decided to reach
for some low hanging fruits: optimizing the database size
Since I have lot of databases a 20-30% reduction in size would make a
difference to me. Whithin one work hour I was able to show that binary
content is possible
After some strange but legal criss cross merging yesterday, monotone
refused its work with the following error:
monotone: fatal: std::runtime_error: cycle in table 'manifest_deltas',
at node b4c5672e5c1a1749b6cf4eb78165e18e6480ff67 -
2a6e1fb46bd1c2f3a197ba0c3a9a3a76428af358 **)
Look at the
Florian Weimer schrieb:
* Christof Petig:
My requirements are very simple: I need to attach a list of {CVS
revision per file} to an existing revision.
Do you need to attach this information to the *revision*, or to a
specific version of a file?
Neither ;-)
Attaching the information
Nathaniel Smith schrieb:
On Tue, Nov 22, 2005 at 09:01:48AM +0100, Christof Petig wrote:
The only additional feature I missed when I developed cvssync was to
attach a file (or some sort of long text) to an already existing
revision. So if you'd ever come near to think about a feature like
Richard Levitte - VMS Whacker schrieb:
I've just been running the test suite over the night, and there seems
to be some memory violation error in some (random?) cases. This is
with a very updated Debian [unstable], so it might not be monotone's
fault at all, but I think it's worth
Richard Levitte - VMS Whacker schrieb:
Here's the tarball.
I suspect you have a space in your path. While monotone itself has no
problems with this, my autotest scripts do not live up to that. Could
you try it in a differently named directory (e.g. /tmp/nvmc)
Christof
PS: I tried to fix the
Richard Levitte - VMS Whacker schrieb:
I'll send you a tarball with the contents of testsuite.dir/18[14], if
that's OK with you.
You didn't comment on these:
christof 185: CVS push with fork and merge FAILED
(t_cvspush_loop.at:42)
christof 188: takeover modified, cvs
Daniel THOMPSON schrieb:
Hi Folks
I am having a play with the cvssync branch (pulled yesterday at approx
23:00 GMT) since it sounds like a really elegant way to interact with
'legacy' source control systems and makes private branches so easy.
It really does. I use it in my daily development
Richard Levitte - VMS Whacker schrieb:
Speaking of the cvssync branch, it fails some tests when doing 'make
check'. Do I need to be worried?
I am. ... checking ...
181: pull of CVS module step by step FAILED
(t_cvspull_separate.at:78)
184: take over a modified CVS checkout
Daniel THOMPSON schrieb:
Hi Folks
I am having a play with the cvssync branch (pulled yesterday at approx
23:00 GMT) since it sounds like a really elegant way to interact with
'legacy' source control systems and makes private branches so easy.
Unfortunately I have been unable to perform
Daniel Carosone schrieb:
On Wed, Oct 12, 2005 at 09:31:34AM +0200, Christof Petig wrote:
I'm at my knowledge's end regarding debugging this under Win32,
using Wine and strace under Linux would be my only option (Why does
Win32 have no strace/ltrace :-( ).
several of the tools
Nathaniel Smith schrieb:
On Fri, Oct 07, 2005 at 12:10:55PM +0200, Christof Petig wrote:
Hi Nathaniel,
I decided to propose merging cvssync in small pieces:
- Win32 pipe abstraction
- cvs_import and cvssync diff apply code (yet to factor out so that both
share the same code,I need to contact
justin handville schrieb:
I was curious whether you had any documentation regarding the
net.venge.monotone.cvssync enhancements that you are working on.
You mean besides the documentation within monotone.texi (aka .info, .pdf)?
I have been evaluating this branch for a few hours, pushing
Hi Nathaniel,
I decided to propose merging cvssync in small pieces:
- Win32 pipe abstraction
- cvs_import and cvssync diff apply code (yet to factor out so that both
share the same code,I need to contact Graydon about this) [that's
index_deltatext(), struct piece etc., most probably this will
Nathaniel Smith schrieb:
On Fri, Oct 07, 2005 at 10:14:21AM +0200, Christof Petig wrote:
I would like to make cvs_push do this functionality: If cvs_push does
not find neither a matching cvs-revisions tag nor a valid module on the
CVS server it should output a message that it is going to commit
Zbynek Winkler schrieb:
Christof Petig wrote:
So here's my first part:
- nonblocking win32 pipe classes. Tested and working on unix, Compiling
and blocking on win32 :-(
By blocking I meant: Not doing anything.
I've not seen your code but maybe this can help with nonblocking pipes
under
Zbynek Winkler schrieb:
It is about how to do nonblocking check on a file descriptor descriptor
to see if there is some data available. It is not as heavy weight as a
full select.
If you need the full select, why don't you try
WaitForMultipleObjects(Ex)? IIRC it should allow you to wait on
1 - 100 of 130 matches
Mail list logo
