darcs repository web UI and hosting app. This is the main darcsden trunk, which also runs hub.darcs.net. (http://hub.darcs.net)

#148implement raw patches, range of patches

  • I would suggest making the url scheme a little more future-proof, so instead of baseUrl/<user>/<repo>/rawpatches/<hash1>..<hash2> maybe baseUrl/<user>/<repo>/rawpatches/hash/<hash1>..<hash2>

    There are some other ways to select subsets and ranges of patches other than with hashes that we may wish to support in the future:

                 --to-match=PATTERN      select changes up to a patch matching PATTERN
                 --to-patch=REGEXP       select changes up to a patch matching REGEXP
                 --to-hash=HASH          select changes up to a patch with HASH
                 --to-tag=REGEXP         select changes up to a tag matching REGEXP
                 --from-match=PATTERN    select changes starting with a patch matching PATTERN
                 --from-patch=REGEXP     select changes starting with a patch matching REGEXP
                 --from-hash=HASH        select changes starting with a patch with HASH
                 --from-tag=REGEXP       select changes starting with a tag matching REGEXP
                 --last=NUMBER           select the last NUMBER patches
      -n N-M     --index=N-M             select a range of patches
                 --matches=PATTERN       select patches matching PATTERN
      -p REGEXP  --patches=REGEXP        select patches matching REGEXP
      -t REGEXP  --tags=REGEXP           select tags matching REGEXP
      -h HASH    --hash=HASH             select a single patch with HASH

    I think the URI scheme should accomodate all of them.

    • added tag experimental
    • added tag wish
  • If you want to do that, we have to adjust the urls for the non-raw patches too to stay consistent.

  • We could declare that a "patch" is represented by a hash and that would make for a backwards-compatible URI scheme:

    baseUrl/<user>/<repo>/patches/<hash1>..<hash2> baseUrl/<user>/<repo>/patches/..<hash2> baseUrl/<user>/<repo>/patches/<hash1>.. baseUrl/<user>/<repo>/patch/<hash>

    baseUrl/<user>/<repo>/raw-patches/<hash1>..<hash2> baseUrl/<user>/<repo>/raw-patches/..<hash2> baseUrl/<user>/<repo>/raw-patches/<hash1>.. baseUrl/<user>/<repo>/raw-patch/<hash>

    baseUrl/<user>/<repo>/tags/<hash1>..<hash2> baseUrl/<user>/<repo>/tags/..<hash2> baseUrl/<user>/<repo>/tags/<hash1>.. baseUrl/<user>/<repo>/tag/<hash>

    baseUrl/<user>/<repo>/raw-tags/<hash1>..<hash2> baseUrl/<user>/<repo>/raw-tags/..<hash2> baseUrl/<user>/<repo>/raw-tags/<hash1>.. baseUrl/<user>/<repo>/raw-tag/<hash>

    and so on...

    However, for consistency, the darcs cli options like --to-patch=REGEXP would have to be renamed or aliased to --to-regexp=REGEXP which is anyway more specific... This reminds me of another thing to consider -- how do we accomodate regexes in the uri scheme with things like ..?