On 29 Apr 2004, at 06:50, Greg Hudson wrote:
> the future. So, if you could write something up in more detail, I'd
> appreciate it.
I'll probably write a paper on it in in summer. I can post that here.
> Also, if you can't release code, it can be tough to be
> sure that one is implementing the algorithm correctly.
True. But then it's so fresh that I don't even know that 100%. I only
have 40 ish test cases.
Still, I was offering to help with that. That is i can read code and
comment. Just our license make write over 10 lines difficult.
And I can spend some time with this, say say 1-3 hours a day for the
next 2 months, so quite substantial.
> Based on your description (which I could not totally understand),
I had hoped it was easy, it is quite simple.
But please do ask, off course I left out details.
> I'm concerned that the algorithm may have O(n) memory requirements for
> n-byte inputs.
This is true. Currently it has all 3 files in memory, plus hashes. But
it can be cut down to 2 at a time.
> We need our diff algorithm to be able to operate
> streamily, reading only sequential chunks of the inputs into memory at
> one time.
That can be done if necessary, though I don't see why. I was not
proposing this as a diff/patch alternative (network or storage
encoding), just for a 3 way merging. And initially only when diff3
fails.
Still it can be done.
Thank you for being interested. I've been using subversion for a year
now and it's great. I'm talking everyone I can into it.
For me subversion has gotten rid of these unnecessary restrictions,
especially file moves. I'd be glad if this algorithm could help to get
rid of quite unnecessary merge conflicts in subversion.
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 29 12:07:35 2004