From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:04
Martin Langhoff [off-list ref] writes:
Do you want just -kv or you'd like to handle all the modes?
No, I do not.
I was just wondering if we are limiting options for people who
want to convert their own CVS repositories by always using
either -kkv or -ko and nothing else. Your simply saying "I do
not think so, -ko is what makes the most sense, and any other
option does not make any sense, but we used to do -kkv so let's
leave that as the default and have a -k option that does -ko" is
enough for me.
It is getting late for me so I'll merge it and push it out
tomorrow when I find time; it will be my day-job day.
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:04
On 8/15/05, Junio C Hamano [off-list ref] wrote:
I was just wondering if we are limiting options for people who
want to convert their own CVS repositories by always using
either -kkv or -ko and nothing else.
I think the other modes are relevant in different scenarios. -kv is
only meaningful as file mode over the life of the file in the repo.
-kk is only meaningful when calling cvs update with -j -j parameters
or cvs diff, and is effectively a synonim of -ko.
In the position we are, getting file/revisions out of a repo, there
are 2 possible files we can get: the one that you'll get with -kkv and
the one you'll get with -ko/-kb. -kb/-ko should give us exactly the
same file, modulo bugs.
I suspect that in practice -kb is more reliable when it comes to
binary files. But to support that the _files() method will need to
handle a slightly different protocol mode on the socket, and I rather
not mess with it unless I can prove its broken. Talking with cvs
servers on the socket is not my idea of fun, and there's all sorts of
version-specific oddities.
cheers,
martin
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:04
On 8/15/05, Martin Langhoff [off-list ref] wrote:
I think the other modes are relevant in different scenarios. -kv is
only meaningful as file mode over the life of the file in the repo.
-kk is only meaningful when calling cvs update with -j -j parameters
or cvs diff, and is effectively a synonim of -ko.
In the position we are, getting file/revisions out of a repo, there
are 2 possible files we can get: the one that you'll get with -kkv and
the one you'll get with -ko/-kb. -kb/-ko should give us exactly the
same file, modulo bugs.
After a few more trial runs, it ends up being that -kb and -ko drop
the ball in some instances, and the most reliable flag to send is -kk.
Don't ask me how or why.
So this patch is obsolete too.
martin
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:04
Martin Langhoff [off-list ref] writes:
So this patch is obsolete too.
I take it to mean that it should be dropped and replaced with
the one you sent today with -kk change.
However, the -kk change one is a corrupted patch and does not
apply. Your MUA ate leading whitespaces, perhaps.
I have already slurped in other two patches to cvsimport in the
proposed updates branch, so could you kindly proofread them (I
am no expert on cvs networking protocol issues) and rebase the
-kk patch, and send it without whitespace corruption this time
around please?
-jc
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:04
On 8/16/05, Junio C Hamano [off-list ref] wrote:
However, the -kk change one is a corrupted patch and does not
apply. Your MUA ate leading whitespaces, perhaps.
I stupidly did a forward. Rebased to your current pu branch and sent.
From now on I'll be sending straight from cmdline.
I have already slurped in other two patches to cvsimport in the
proposed updates branch, so could you kindly proofread them (I
am no expert on cvs networking protocol issues)
Proofread. I don't claim to have understood 100% but it made sense.
Most importantly, it imported several repos perfectly.
cheers,
martin