tolsen / litmus

[stokito]

There is a fork https://github.com/tolsen/litmus It has some changes that probably are useful. Could you please grab them?

[gstrauss]

@stokito Your post is low-effort and low-knowledge (and I pattern I have seen from you elsewhere).

It has some changes that probably are useful.

Please enumerate those changes.

I do not think @notroj should waste any time reviewing commits like the following, from 2008:

commit 3ad2592a88c84063e80e2677b55cae718115d718
Author: Git Admin <git-admin@git.limebits.net>
Date:   Mon Oct 27 16:23:08 2008 +0000

    apply limebits' changes

...
 71 files changed, 5615 insertions(+), 4406 deletions(-)

[skissane]

I tried to work out what the changes are. It is actually rather difficult, because the two Git repos have no actual history in common. Comparing them, there are also lots of junk differences, like differences in whitespace.

Here's my best attempt to remove all the irrelevant changes and keep only the possibly relevant ones: https://github.com/notroj/litmus/compare/master...skissane:litmus:tolsen-merge

I think some of them may have some value, but quite a lot of work remains in analysing them all and working out what is truly useful and what isn't. I've done all I'm going to do for now, but I may come back to this at some point.

@stokito since you opened this issue, maybe you could help with analysing them? I was going to suggest that each of the changed files could be analysed separately, so maybe start with the first one and work through evaluating the changes any extracting any useful ones into a separate issue/PR per file?

commit 9418615b040d65dd77d7eb48744b1a2348b1243f (HEAD -> tolsen-merge, origin/tolsen-merge)
Author: Simon Kissane <skissane@gmail.com>
Date:   Sat Jun 17 18:58:36 2023 +1000

    Tim Olsen fork changes

    Attempt to manually merge:
       https://github.com/tolsen/litmus/commit/4d04ea01cd16574b8046d547aa5b773715372994
    with
       https://github.com/notroj/litmus/commit/cbc3e8a76f70461fbf3dcf88c5b27637969576cc

    I tried my best to exclude irrelevancies such as differences in whitespace.
    Unfortunately my doing so has stuffed up some of the indendation.

    Anyway, probably not all of these changes are useful, but some may be.
    At least this exercise has (hopefully) made clearer what they are.

 Dockerfile     |   6 ++
 src/basic.c    | 127 ++++++++++++++++++++++++++++++++++++++++
 src/common.c   | 123 +++++++++++++++++++++++++++++---------
 src/copymove.c | 403 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------
 src/locks.c    | 602 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
 src/props.c    | 514 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
 6 files changed, 1643 insertions(+), 132 deletions(-)

[stokito]

@skissane good job, thank you. I can't really help here but it looks like it makes sense to test a webdav implementation with both litmuses. If you are making a new implementation it may be useful for you to check this list of already existing servers https://github.com/WebDAVDevs/awesome-webdav#servers

[tolsen]

Yes, this is the difficulty. litmus predates git. So my svn -> git conversion will be different than another's. I'll look now

[tolsen]

ok, I've looked things over.

There are quite a number of new tests. You might consider adding them, but I would not take them necessarily as a gold standard. These were written by developers fresh out of school at the time (I was the lead developer at the time and did not touch this particular code base).

To truly ascertain the value of these tests I recommend having someone with an in-depth knowledge of webdav looking them over. That would have been me 15 years ago, but you can imagine I'm quite rusty now.

This is the best book to read to learn WebDAV in depth: https://www.amazon.com/WebDAV-Next-Generation-Collaborative-Web-Authoring/dp/0130652083 . Lisa, the author, goes into not only the details, but explains the problems with some of the specs (especially DeltaV). She was on a number of working groups that worked on various RFCs. I believe she was particularly involved with CalDAV.

My personal opinion with the WebDAV specs is that they're overall good, but DeltaV is atrocious. DeltaV is barely more than ClearCase translated to work with WebDAV. The spec leaves quite a number of edge cases unresolved.

Also, if you are looking for even more webdav tests, we did not spend a lot of time adding tests to litmus. At some point we switched over to writing tests in Ruby. Here are even more tests:

https://github.com/tolsen/rubydav/tree/master/test

Unfortunately I think some of those tests were specific to the implementation and were testing some extra, non-compliant features. I remember trying to get the developers to separate them out, but I don't believe I was successful if I remember correctly. Again, someone with in-depth knowledge of WebDAV should go over these (if you're interested in them).

[notroj]

Thanks @stokito and @tolsen. I'm not against merging some of these changes but they would need to be cut down into smaller set of patches which are possible to review.