Markus Wanner wrote:
Hendrik Boom wrote:
Well, it's possible the topological analysis of the CVS repository could
generate a different graph if a few entries have been added.
With just using cvs commit to write to the cvs repository, that should
not be possible, no matter how silly your
:
Note that git has the ability to represent more than two ancestors for a
merged revision, which monotone does not. Not that it's an often used
feature, but IIRC cvs2git is one of its users. (I vaguely remember
discussing these issues with Michael Haggerty, author of cvs2svn. See
that project's
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
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
Markus Schiltknecht wrote:
Jon Smirl wrote:
I have been trying with cvs2svn for three months now and progress
isn't happening. You at least seem interested in making things work
right for Mozilla.
I don't think so. The graph algorithm is just very new and we still have
to experiment with
Markus Schiltknecht wrote:
By introducing symbol dependencies (which svn2cvs does not do) you can
force the second change set sequence to be generated.
Uhm.. is there a reason for not adding such symbol dependencies? It
seems obvious that branching and tagging should be handled by the
Nathaniel Smith writes:
I just read over the thread on the cvs2svn list about this -- I have a
few random thoughts. Take them with a grain of salt, since I haven't
actually tried writing a CVS importer myself...
Regarding the basic dependency-based algorithm, the approach of
throwing
Markus Schiltknecht wrote:
Michael Haggerty wrote:
The main problem with converting CVS repositories is its unreliable
timestamps. Sometimes they are off by a few minutes; that would be no
problem for your algorithm. But they might be off by hours (maybe a
timezone was set incorrectly
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
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
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
12 matches
Mail list logo
