On Fri, Sep 15, 2006 at 11:39:18PM -0400, Shawn Pearce wrote:
On the other hand from what I understand of Monotone it needs
the revisions in oldest-newest order, as does SVN.
Doing both orderings in cvs2noncvs is probably ugly.
don't worry, as i know mike, he'll come up with an abstract,
On Fri, Sep 15, 2006 at 11:39:18PM -0400, Shawn Pearce wrote:
On the other hand from what I understand of Monotone it needs
the revisions in oldest-newest order, as does SVN.
Monotone stores file deltas new-old, similar to git. It should be
reasonably efficient at turning them around if it has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathaniel Smith wrote:
On Wed, Sep 13, 2006 at 04:42:01PM -0700, Keith Packard wrote:
However, this means that parsecvs must hold the entire tree state in
memory, which turned out to be its downfall with large repositories.
Worked great for all of
Markus Schiltknecht [EMAIL PROTECTED] wrote:
Shawn Pearce wrote:
I don't know how the Monotone guys feel about it but I think Git
is happy with the data in any order, just so long as the dependency
chains aren't fed out of order. Which I think nearly all changeset
based SCMs would have an
Michael Haggerty [EMAIL PROTECTED] wrote:
The only difference between our SCMs that might be difficult
to paper over in a universal dumpfile is that SVN wants its changesets
in chronological order, whereas I gather that others would prefer the
data in dependency order branch by branch.
This
Jakub Narebski [EMAIL PROTECTED] wrote:
Shawn Pearce wrote:
Originally I wanted Jon Smirl to modify the cvs2svn (...)
By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly
available?
Yes. I want to submit git-fast-import to the main Git project and
ask Junio to bring
Shawn Pearce wrote:
Originally I wanted Jon Smirl to modify the cvs2svn (...)
By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly
available?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
___
Monotone-devel mailing list
On 9/14/06, Jakub Narebski [EMAIL PROTECTED] wrote:
Shawn Pearce wrote:
Originally I wanted Jon Smirl to modify the cvs2svn (...)
By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly
available?
It has some unresolved problems so I wasn't spreading it around everywhere.
Michael Haggerty wrote:
Alternatively, there was a suggestion to add heuristics to guess which
files' unlabeled branches actually belong in the same original branch.
This would be a lot of work, and the result would never be very
accurate (for one thing, there is no evidence of the branch
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 9/14/06, Jakub Narebski [EMAIL PROTECTED] wrote:
Shawn Pearce wrote:
Originally I wanted Jon Smirl to modify the cvs2svn (...)
By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly
available?
On Thu, Sep 14, 2006 at 11:50:03AM -0400, Shawn Pearce wrote:
I don't know how the Monotone guys feel about it but I think Git
is happy with the data in any order, just so long as the dependency
chains aren't fed out of order. Which I think nearly all changeset
based SCMs would have an issue
Let's copy the git list too and maybe we can come up with one importer
for everyone.
On 9/13/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Hi,
I've been trying to understand the cvsimport algorithm used by monotone
and wanted to adjust that to be more like the one in cvs2svn.
I've had some
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt at that. One thing that bothers me in the cvs2svn algorithm
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt at that.
BTW: good point, I always thought about cvsps.
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt at that. One thing that bothers me in the cvs2svn algorithm is
that is not stable
On Wed, Sep 13, 2006 at 11:04:13PM +0200, Markus Schiltknecht wrote:
Martin Langhoff wrote:
One thing that bothers me in the cvs2svn algorithm is
that is not stable in its decisions about where the branching point is
-- run the import twice at different times and it may tell you that
the
On 9/14/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt
On 9/13/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while a (limited, buggy)
attempt
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
But aside from this point, I think an intrinsic part of implementing
incremental conversion is convert the subsequent changes to the CVS
repository *subject to the constraints* imposed by decisions made in
earlier conversion runs. And the
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
IIRC, it places branch tags as late as possible. I haven't looked at
it in detail, but an import immediately after the first commit against
the branch may yield a different branchpoint from the same import done
a bit later.
This is
Martin Langhoff wrote:
On 9/14/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
It's a really good idea. cvsps has been for a while
Jon Smirl wrote:
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
But aside from this point, I think an intrinsic part of implementing
incremental conversion is convert the subsequent changes to the CVS
repository *subject to the constraints* imposed by decisions made in
earlier
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
2. Long-term continuous mirroring (backwards and forwards) between CVS
and another SCM, to allow people to use their preferred tool. (I
actually think that this is a silly idea, but some people seem to like it.)
Call me silly ;-) I use
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
But aside from this point, I think an intrinsic part of implementing
incremental conversion is convert the subsequent changes to the CVS
repository *subject to the
Martin Langhoff wrote:
On 9/14/06, Michael Haggerty [EMAIL PROTECTED] wrote:
2. Long-term continuous mirroring (backwards and forwards) between CVS
and another SCM, to allow people to use their preferred tool. (I
actually think that this is a silly idea, but some people seem to like
it.)
Jon Smirl wrote:
On 9/13/06, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Martin Langhoff wrote:
On 9/14/06, Jon Smirl [EMAIL PROTECTED] wrote:
Let's copy the git list too and maybe we can come up with one importer
for everyone.
That would be great.
AFAIK none of the CVS converters are
26 matches
Mail list logo
