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 user-testable stage?
All the test scripts in tests/common have been moved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[sorry if this message is duplicated, but I don't see the first one on
mailing list, so I'm re-sending it]
Hi there.
I was thinking about using "cvssync" in a project of mine that
involves many CVS users (moreover most of them are non-programmers and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there.
I was thinking about using "cvssync" in a project of mine that
involves many CVS users (moreover most of them are non-programmers and
I convinced them to use CVS only thanks to TortoiseCVS ^_^) but I
would like to use monotone nonetheless if
-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 th
On 21/02/2007, at 8:40 AM, Christof Petig wrote:
Is this at a user-testable stage?
Yes, though prepare for problems here or there (I don't know of any
yet,
though). But you will be the second to first person on earth using
that
code.
*Will finds a nice BIG artery for the leading edge
-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 ambi
Hi all, me again :)
Using this cvssync refactor branch I've got some gotchas/bugs...
Because mtn_cvs is now using mtn automate to get at the database, it
doesn't seem to have a transaction wrapped about everything any
more. This means that if something goes wrong during an mtn_cvs
opera
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 that freezes.
I've traced the problem back to mtn_automate::get_sync_info(
Hi,
I just tried the current head from the .cvssync branch, and got a
spectacular error :-):
: ; ./monotone --db=db.foo --branch=free.lp.se:X.ctwm cvs_pull :pserver:[EMAIL
PROTECTED]:/orgs/lp/free/cvs X/ctwm
enter passphrase for key ID [EMAIL PROTECTED]:
monotone: bytes in | bytes out
monotone:
done:
- pull,push,takeover work
- win32 port (untested by me, but compiles)
- documentation
- tests for pull,push,takeover (though push coverage could be better)
open issues:
- --direction missing (for resolving forks on push) *
- --cvsbranch missing (working with side branches in CVS)
- strange
I've been playing with this a little bit. Remote CVS version is
1.11.20. (Note that I have verify_depth set to 0 in this build, but I
checked that the problems happen in the same place with the default.)
One problem:
:; monotone-cvssync -d ~/somat.db -b com.somat.cvs.test cvs_pull :ext:[EMAIL
Hi all,
It's been a long time since I've hacked on monotone. At work we use CVS for
our development, and for a variety of reasons that's not likely to change.
The group I work with would like to set up a sort of experimental
development repository to allow us to hack on stuff that is potentially
Lapo Luchini schrieb:
> What's the current status?
It has been ported to rosters. [But I still use the 0.25 version] My
idea to separate it from monotone has stalled due to lack of development
time.
> Is out there any "documentation" how to use it?
Look into monotone.texi within the branch (and
On Fri, Mar 09, 2007 at 07:20:34PM +1100, William Uther wrote:
> Because mtn_cvs is now using mtn automate to get at the database, it
> doesn't seem to have a transaction wrapped about everything any
> more. This means that if something goes wrong during an mtn_cvs
> operation, the mtn datab
On 09/03/2007, at 8:03 PM, Nathaniel Smith wrote:
On Fri, Mar 09, 2007 at 07:20:34PM +1100, William Uther wrote:
Because mtn_cvs is now using mtn automate to get at the database, it
doesn't seem to have a transaction wrapped about everything any
more. This means that if something goes wrong
Hi,
I'm not sure if this is interesting to everyone. It's mostly for
Christof Petig I expect. BTW - there is no rush on this any more.
Everyone has moved back to CVS for the moment until I get cvs-sync
running stably for a while. So far my record between glitches is 2
whole days :).
-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 that
On 20/03/2007, at 1:20 PM, Christof Petig wrote:
i) Either mtn_automate::get_sync_info() should be falling back
to file
attributes when the cert doesn't contain the info it needs, or
Whatever writes the sync info into the cert needs to add sync
info
for all files in the revision. (
Richard Levitte - VMS Whacker schrieb:
> I just tried the current head from the .cvssync branch, and got a
> spectacular error :-):
>
> monotone: fatal: std::logic_error: cvs_client.cc:1465: invariant
> 'I(lresult[0].second=="Clear-static-directory")' violated
>
> The anonymous account has an empt
Christof Petig schrieb:
>>monotone: fatal: std::logic_error: cvs_client.cc:1465: invariant
>>'I(lresult[0].second=="Clear-static-directory")' violated
>
> I tried and will fix it (today?). CVS server seem to vary greatly when
> it comes to responses ... I tried on all servers I could get my hand o
Christof Petig schrieb:
> => /orgs/lp/free/cvs/X/ctwm/
> => M RCS file: /home/orgs/lp/free/cvs/X/ctwm/.cvsignore,v
>
> So how is this file to be called in client space?
>
> [ok, I can readd the feature of stripping arbitrary paths components off
> the RCS file, but I was glad to have found a way to
Let me start by saying that the cvssync branch is the best CVS history
preserving converter I have used. If you are targeting monotone as the
new SCM then cvssync is heads above tailor.py in terms of speed and
correct file generation. I got exactly what I wanted from the cvssync
branch in alm
In message <[EMAIL PROTECTED]> on Sun, 18 Sep 2005 01:23:07 +0200, Christof
Petig <[EMAIL PROTECTED]> said:
christof> open issues:
christof>
christof> - --direction missing (for resolving forks on push) *
christof> - --cvsbranch missing (working with side branches in CVS)
christof> - strange mod
On Sun, Sep 18, 2005 at 01:23:07AM +0200, Christof Petig wrote:
> So I would consider it ready for inclusion into mainline (to get more
> testing by other people)
Cool! Looking over the code:
= General issues =
What are these files?:
- WhyThisWay
- CVS_prot
- pipe_test_client.c
- tests.cvs/
Nathaniel Smith schrieb:
> On Sun, Sep 18, 2005 at 01:23:07AM +0200, Christof Petig wrote:
>
>>So I would consider it ready for inclusion into mainline (to get more
>>testing by other people)
It had been ready for review.
> Cool! Looking over the code:
>
> = General issues =
>
> What are thes
* Richard Levitte:
> Can you say how it handles a CVS history where some files have been
> re-tagged?
Is re-tagging visible in the CVS repository at all?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinf
Nathaniel Smith wrote:
Can you give more details on how you reconstruct whole tree-states
from CVS's file-state information? I ask in particular because I
notice code that looks like the old cvs importer, but the cvs importer
was recently rewritten because the tree state reconstruction stuff
tu
* Zbynek Winkler:
> Has it been considered to let someone else do this work for monotone? I
> think git is using cvsps [1] to import cvs repositories.
Does cvsps still open one connection per file and revision? That
behavior was rather antisocial.
_
Florian Weimer wrote:
* Zbynek Winkler:
Has it been considered to let someone else do this work for monotone? I
think git is using cvsps [1] to import cvs repositories.
Does cvsps still open one connection per file and revision? That
behavior was rather antisocial.
According to th
Zbynek Winkler schrieb:
> Nathaniel Smith wrote:
>
>> Can you give more details on how you reconstruct whole tree-states
>> from CVS's file-state information? I ask in particular because I
>> notice code that looks like the old cvs importer, but the cvs importer
>> was recently rewritten because
In message <[EMAIL PROTECTED]> on Mon, 19 Sep 2005 20:09:00 +0200, Florian
Weimer <[EMAIL PROTECTED]> said:
fw> * Richard Levitte:
fw>
fw> > Can you say how it handles a CVS history where some files have
fw> > been re-tagged?
fw>
fw> Is re-tagging visible in the CVS repository at all?
Not dire
On Mon, Sep 19, 2005 at 10:53:44PM +0200, Christof Petig wrote:
> Tools to import CVS repositories are numerous. Cvssync offers the
> promise to export monotone repositories to CVS (it already works on
> existing CVS projects) and here is my main focus.
For what it's worth, I'm told that the lates
On Mon, Sep 19, 2005 at 01:35:07PM +0200, Christof Petig wrote:
> Nathaniel Smith schrieb:
> > On Sun, Sep 18, 2005 at 01:23:07AM +0200, Christof Petig wrote:
> >
> >>So I would consider it ready for inclusion into mainline (to get more
> >>testing by other people)
>
> It had been ready for revie
Christof Petig wrote:
Nathaniel Smith schrieb:
== Formatting ==
Please format code appropriatly (= GNU style). Really. I know it
seems trivial, and I hate to be annoying about it. But it's
important, and it _is_ trivial, so I hope this isn't a big deal.
Code on mainline needs to be easily ma
Nathaniel Smith schrieb:
> On Mon, Sep 19, 2005 at 01:35:07PM +0200, Christof Petig wrote:
>>>What does the cvs_admin command do?
>>
>>... looking into the code ...
>>
>>monotone cvs_admin manifest
>>
>>gives you each CVS revision and path name of a manifest. [I mostly used
>>this for debugging, i
Hi,
Christof Petig wrote:
In the broad scheme of things, I'm not quite sure what to say. I
don't really want to drop more things on our few valiant win32
maintainers; they already do a heroic enough job keeping things
running at all... but perhaps someone else will find this
functionality intr
On Tue, Sep 27, 2005 at 02:34:33PM -0500, Brian Downing wrote:
> Debug log attached as debug1.gz.
> Debug log attached as debug2.gz.
Er, oops.
-bcd
debug1.gz
Description: application/gunzip
debug2.gz
Description: application/gunzip
___
Monotone-deve
Brian Downing schrieb:
> monotone: fatal: std::logic_error: cvs_sync.cc:847: invariant
> 'I(!e->xfiles.empty())' violated
It looks like this node/edge contains no files, for now I removed the
invariant check and print a warning, can you check whether this
- really is the case
- works as expected
On Wed, Sep 28, 2005 at 12:30:17PM +0200, Christof Petig wrote:
> Brian Downing schrieb:
> > monotone: fatal: std::logic_error: cvs_sync.cc:847: invariant
> > 'I(!e->xfiles.empty())' violated
>
> It looks like this node/edge contains no files, for now I removed the
> invariant check and print a w
On 9/29/05, Brian Downing <[EMAIL PROTECTED]> wrote:
> One other comment I have is that it's kind of suboptimal for me to have
> the "Monotone revision . author . time ." as the very first
> line of the CVS comments, as it uses up the space in ViewCVS output that
> would otherwise be us
Bill Marquette schrieb:
> On 9/29/05, Brian Downing <[EMAIL PROTECTED]> wrote:
>
>>One other comment I have is that it's kind of suboptimal for me to have
>>the "Monotone revision . author . time ." as the very first
>>line of the CVS comments, as it uses up the space in ViewCVS output
Ooopps...reply-all :)
-- Forwarded message --
From: Bill Marquette <[EMAIL PROTECTED]>
Date: Sep 30, 2005 10:53 AM
Subject: Re: [Monotone-devel] Cvssync problems
To: Christof Petig <[EMAIL PROTECTED]>
On 9/30/05, Christof Petig <[EMAIL PROTECTED]> wrote:
Hi,
Emile Snyder wrote:
> Does anyone use any of these branches at the moment for working on code
> whose canonical repo is the CVS version? Are they stable enough for you?
I'm working on nvm.cvsimport-branch-reconstruction, which is based on
the concepts of cvs2svn 2.0, fiddling with the DAG to
Hi Markus, thanks for the info. The cvs import stuff is all for one-time
moving from CVS to monotone changes right? Unfortunately, we won't have
that luxury ;)
thanks,
-emile
On Fri, Jan 23, 2009 at 2:06 AM, Markus Wanner wrote:
> Hi,
>
> Emile Snyder wrote:
> > Does anyone use any of these b
Hi,
Emile Snyder wrote:
> Hi Markus, thanks for the info. The cvs import stuff is all for one-time
> moving from CVS to monotone changes right? Unfortunately, we won't have
> that luxury ;)
Right. (I'm planning on supporting subsequent imports, but... )
Regards
Markus Wanner
__
> "Matt" == Matt Lavin <[EMAIL PROTECTED]> writes:
Matt> If you are targeting monotone as the new SCM then cvssync is
Matt> heads above tailor.py in terms of speed and correct file
Matt> generation.
No doubt on former, given the different overall goals of the two,
but I'd like to
I hope I didn't appear to be slamming tailor.py, I was trying mostly to
compliment cvssync. I'll try to clear up some of my statements.
1. "correct file generation" should have been "correct directory
contents". I have a rather large project that I was trying to convert (
~3500 patches) and
> "Matt" == Matt Lavin <[EMAIL PROTECTED]> writes:
Matt> I'll try to clear up some of my statements.
Thank you, appreciated!
Matt> 1. ... For the tailor.py build project I had a couple of
Matt> extra empty directories and 1 missing file. One thing I
Matt> noticed about the
Hi Nathaniel, hi monotoners,
what do you think about separating cvssync from the monotone core since
I realized that tailor, the git branch and others to come (svn,...) do
only use a small subset of monotone's features. Also for cvssync the
network latency/bandwidth should be the limiting factor,
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 code in .cvssync splits this up
-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 v1.4.1
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 c
Hi Nathaniel,
Hi Jon (Bright),
while dusting off the ssh (and serve stdio) branch I realized that all
these works need a common infrastructure: The ability to
(cross-platform!) deal with pipes.
Since serve stdio seemed the least intrusive I looked into separating it
from the rest ... but ...
ser
Christof,
I'm playing with your cvssync branch right now, and I've hit a problem.
I'm trying to import the PostgreSQL repository using cvs_pull, and it
fails with
monotone: fatal: std::logic_error: cvs_client.cc:934: invariant
'I(begins_with(result,"revision ",len))' violated
I discovered the
On Wed, May 25, 2005 at 09:45:53AM +0200, Christof Petig wrote:
> while dusting off the ssh (and serve stdio) branch I realized that all
> these works need a common infrastructure: The ability to
> (cross-platform!) deal with pipes.
Actually, 'automate stdio' should be doable by making stdin
non-b
On Wed, 2005-05-25 at 21:46 -0700, Nathaniel Smith wrote:
> On Wed, May 25, 2005 at 09:45:53AM +0200, Christof Petig wrote:
> > while dusting off the ssh (and serve stdio) branch I realized that all
> > these works need a common infrastructure: The ability to
> > (cross-platform!) deal with pipes.
Alvaro Herrera schrieb:
> (There are earlier later revisions of course, which I omitted). Note
> that r1.3 cites the 1.2 log entry, with the dashes line included :-(
> For now I just edited the ,v file to make that line not look like a
> revision separator, but if you have a better suggestion, i.e
57 matches
Mail list logo
