Re: [PATCH] use SHA-2 family hash for releases
Andreas Stieger wrote on Thu, Feb 23, 2017 at 21:08:43 +0100: > +++ tools/dist/release.py (working copy) > @@ -537,9 +537,9 @@ def roll_tarballs(args): > > shutil.move(filename, get_deploydir(args.base_dir)) > filename = os.path.join(get_deploydir(args.base_dir), filename) > -m = hashlib.sha1() > +m = hashlib.sha512() > m.update(open(filename, 'r').read()) > -open(filename + '.sha1', 'w').write(m.hexdigest()) > +open(filename + '.sha512', 'w').write(m.hexdigest()) Should we keep generating both .sha1 and .sha512 for a transition period?
Re: 1.10.0-alpha2 is up for signing
On 2/21/2017 13:54, Stefan Sperling wrote: > The new 1.10.1-alpha2 release is up for signing. > > The proposed 1.10.0-alpha1 release had a compilation problem on Windows. > The alpha2 release should fix this problem. It is based on trunk@r1783880. > > Full committers, please get this release from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Thank you! Building the new svnconflict tool I'm getting the following linker errors: error LNK2001: unresolved external symbol svn_diff_version error LNK2001: unresolved external symbol svn_delta_version (that is: with Visual Studio 2015Up3). Applying the attached patch resolves the build issue for me. Regards, Stefan Index: build.conf === --- build.conf (revision 1783959) +++ build.conf (working copy) @@ -1712,4 +1712,4 @@ type = exe path = tools/client-side/svnconflict install = tools -libs = libsvn_client libsvn_wc libsvn_ra libsvn_subr apriconv apr +libs = libsvn_client libsvn_wc libsvn_diff libsvn_delta libsvn_ra libsvn_subr apriconv apr
New MaxSVN releases (incl. 1.8.17 and 1.9.5)
Hi, I'm happy to announce the release of new MaxSVN versions today: - 1.7.22-6 - 1.8.17-1 - 1.9.5-1 - trunk-dev-r1771118-1 These versions were built with an updated set of dependencies/build tools: - VS 2015 Update 3 - ActivePerl 5.24.0.2400 - CMake 3.7.0 - NASM 2.12.02 (replacing usage of ml64.exe) - Python 2.7.12 - SCons 2.5.1 - Apache httpd 2.4.23 - Apache Serf 1.3.9 - Expat 2.2.0 - Neon 0.30.2 - OpenSSL 1.0.2j - PCRE 8.39 - SQLite 3.15.1 Highlights in these versions are: - improved SVN test coverage - tests cover for tests requiring elevated privileges - ensuring deployed content is actually tested - MaxSVN 1.7.x: [fsfs] x [ra_local | ra_serf (http) | ra_neon (http)] - MaxSVN 1.8.x: [fsfs] x [ra_local | ra_serf (http)] - MaxSVN 1.9.x: [fsfs | fsx] x [ra_local | ra_serf (http)] - MaxSVN trunk: [fsfs | fsx] x [ra_local | ra_serf (http) | ra_serf (https)] - All MaxSVN versions ship with all available standard SVN tools now. - MaxSVN trunk: Contains the svn mergeinfo normalizer tool again which was missed in the previous version. - MaxSVN trunk: Contains a fix for a deadlock condition when utilizing the experimental fsx filesystem. - Notable build environment changes - Apache httpd builds integrate OpenSSL now (for https-testcoverage and to make a step towards a feature complete SVN build environment). - OpenSSL is built using NASM now (previous builds relied on the Microsoft assembler (ml64.exe). Please note that normally we'd have shipped this version with OpenSSL 1.1.0c. However, we decided to postpone an upgrade to OpenSSL 1.1.0 for the time being due to Apache httpd not having a compatible release available just yet. MaxSVN homepage: http://www.luke1410.de/typo3/index.php?id=97 MaxSVN bugtracker: http://www.luke1410.de:8090/browse/MAXSVN About MaxSVN MaxSVN is a highly experimental distribution of Apache™ Subversion® (SVN) for Windows. MaxSVN is ***NOT*** meant/designed for production use. If you are looking for an SVN distribution for daily use, please check out the alternative SVN distributions for Windows. A partial list is provided here: https://subversion.apache.org/packages.html#windows MaxSVN's main purpose is to be used for development of Subversion itself and for providing a distribution which can be used to test features/builds as early as possible. The aim is to provide: - a distribution which tests SVN against the latest build tools and dependencies on Windows - provide early access to versions of SVN while they are in development - provide a distribution which can be used to debug/test issues yourself (by providing symbol files) Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] use SHA-2 family hash for releases
On 23/02/17 21:08, Andreas Stieger wrote:
After the alpha, the next release should go up with a SHA-2 family
digest.
And some cleanup patches, even though this does not currently seem to be
part of the release pipeline:
sha-2-dist.patch
[[[
* tools/dist/dist.sh: also print SHA-512
]]]
sha-2-checksums-py.patch
[[[
* tools/dist/checksums.py: support SHA-512
]]]
sha-2-cleanup.patch
[[[
* tools/dist/download-release.sh: remove unused script
]]]
Andreas
Index: tools/dist/checksums.py
===
--- tools/dist/checksums.py (revision 1784199)
+++ tools/dist/checksums.py (working copy)
@@ -19,12 +19,14 @@
# under the License.
#
#
-# Check MD5 and SHA1 signatures of files, using md5sums and/or
-# sha1sums as manifests. Replaces the 'md5sum' and 'sha1sum' commands
+# Check MD5 and SHA-1 and SHA-2 signatures of files, using
+# md5sums, sha1sums, and/or sha512sums as manifests
+# Replaces the 'md5sum', 'sha1sum', and 'sha512sums' commands
# on systems that do not have them, such as Mac OS X or Windows.
#
# Usage: checksums.py [manifest]
-# where "os.path.basename(manifest)" is either "md5sums" or "sha1sums"
+# where "os.path.basename(manifest)" is either "md5sums", "sha1sums",
+# "sha512sums"
#
# Tested with the following Python versions:
#2.4 2.5 2.6 2.7 3.2
@@ -37,6 +39,7 @@ import sys
try:
from hashlib import md5
from hashlib import sha1
+from hashlib import sha512
except ImportError:
from md5 import md5
from sha import sha as sha1
@@ -67,9 +70,11 @@ def main(manipath):
sink = Digester(md5)
elif manifest == 'sha1sums':
sink = Digester(sha1)
+elif manifest == 'sha512sums':
+sink = Digester(sha512)
else:
raise ValueError('The name of the digest manifest must be '
- "'md5sums' or 'sha1sums', not '%s'" % manifest)
+ "'md5sums', 'sha1sums', or 'sha512sums', not '%s'" % manifest)
# No 'with' statement in Python 2.4 ...
stream = None
Index: tools/dist/dist.sh
===
--- tools/dist/dist.sh (revision 1784199)
+++ tools/dist/dist.sh (working copy)
@@ -369,9 +369,10 @@ sign_file()
fi
}
-# allow md5sum and sha1sum tool names to be overridden
+# allow md5sum, sha1sum, and sha512sum tool names to be overridden
[ -n "$MD5SUM" ] || MD5SUM=md5sum
[ -n "$SHA1SUM" ] || SHA1SUM=sha1sum
+[ -n "$SHA512SUM" ] || SHA512SUM=sha512sum
echo ""
echo "Done:"
@@ -387,6 +388,12 @@ if [ -z "$ZIP" ]; then
echo "sha1sums:"
$SHA1SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
fi
+ type $SHA512SUM > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sums:"
+$SHA512SUM "$DISTNAME.tar.bz2" "$DISTNAME.tar.gz"
+ fi
else
ls -l "$DISTNAME.zip"
sign_file $DISTNAME.zip
@@ -399,4 +406,10 @@ else
echo "sha1sum:"
$SHA1SUM "$DISTNAME.zip"
fi
+ type $SHA512SUM > /dev/null 2>&1
+ if [ $? -eq 0 ]; then
+echo ""
+echo "sha512sum:"
+$SHA512SUM "$DISTNAME.zip"
+ fi
fi
Index: tools/dist/download-release.sh
===
--- tools/dist/download-release.sh (revision 1784199)
+++ tools/dist/download-release.sh (nonexistent)
@@ -1,28 +0,0 @@
-#!/bin/bash
-#
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-#
-BASEURL=$1
-VERSION=$2
-wget -nc $BASEURL/{{md5,sha1}sums,svn_version.h.dist,subversion{-deps,}-$VERSION.{{zip,tar.bz2}{.asc,},tar.gz.asc}}
-bzip2 -dk subversion{-deps,}-$VERSION.tar.bz2
-gzip -9n subversion{-deps,}-$VERSION.tar
-md5sum -c md5sums
-sha1sum -c sha1sums
Property changes on: tools/dist/download-release.sh
___
Deleted: svn:eol-style
## -1 +0,0 ##
-native
\ No newline at end of property
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property
[PATCH] use SHA-2 family hash for releases
Hello,
After the alpha, the next release should go up with a SHA-2 family digest.
[[[
Use SHA-512 for releases
* tools/dist/release.py: generate SHA-512 digests
* tools/dist/templates/download.ezt
tools/dist/templates/rc-release-ann.ezt
tools/dist/templates/stable-release-ann.ezt: adjust text and variable
]]]
Andreas
Index: tools/dist/release.py
===
--- tools/dist/release.py (revision 1784199)
+++ tools/dist/release.py (working copy)
@@ -537,9 +537,9 @@ def roll_tarballs(args):
shutil.move(filename, get_deploydir(args.base_dir))
filename = os.path.join(get_deploydir(args.base_dir), filename)
-m = hashlib.sha1()
+m = hashlib.sha512()
m.update(open(filename, 'r').read())
-open(filename + '.sha1', 'w').write(m.hexdigest())
+open(filename + '.sha512', 'w').write(m.hexdigest())
shutil.move('svn_version.h.dist',
get_deploydir(args.base_dir) + '/' + 'svn_version.h.dist'
@@ -758,39 +758,39 @@ def write_news(args):
template.generate(sys.stdout, data)
-def get_sha1info(args, replace=False):
-'Return a list of sha1 info for the release'
+def get_sha512info(args, replace=False):
+'Return a list of sha512 info for the release'
target = get_target(args)
-sha1s = glob.glob(os.path.join(target, 'subversion*-%s*.sha1' % args.version))
+sha512s = glob.glob(os.path.join(target, 'subversion*-%s*.sha512' % args.version))
class info(object):
pass
-sha1info = []
-for s in sha1s:
+sha512info = []
+for s in sha512s:
i = info()
-# strip ".sha1"
-fname = os.path.basename(s)[:-5]
+# strip ".sha512"
+fname = os.path.basename(s)[:-7]
if replace:
# replace the version number with the [version] reference
i.filename = Version.regex.sub('[version]', fname)
else:
i.filename = fname
-i.sha1 = open(s, 'r').read()
-sha1info.append(i)
+i.sha512 = open(s, 'r').read()
+sha512info.append(i)
-return sha1info
+return sha512info
def write_announcement(args):
'Write the release announcement.'
-sha1info = get_sha1info(args)
+sha512info = get_sha512info(args)
siginfo = "\n".join(get_siginfo(args, True)) + "\n"
data = { 'version' : str(args.version),
- 'sha1info' : sha1info,
+ 'sha512info' : sha512info,
'siginfo' : siginfo,
'major-minor' : args.version.branch,
'major-minor-patch': args.version.base,
@@ -809,10 +809,10 @@ def write_announcement(args):
def write_downloads(args):
'Output the download section of the website.'
-sha1info = get_sha1info(args, replace=True)
+sha512info = get_sha512info(args, replace=True)
data = { 'version' : str(args.version),
- 'fileinfo' : sha1info,
+ 'fileinfo' : sha512info,
}
template = ezt.Template(compress_whitespace = False)
Index: tools/dist/templates/download.ezt
===
--- tools/dist/templates/download.ezt (revision 1784199)
+++ tools/dist/templates/download.ezt (working copy)
@@ -2,12 +2,12 @@
File
- Checksum (SHA1)
+ Checksum (SHA-512)
Signatures
[for fileinfo]
[fileinfo.filename]
- [fileinfo.sha1]
+ [fileinfo.sha512]
[http://www.apache.org/dist/subversion/[fileinfo.filename].asc";>PGP]
[end]
Index: tools/dist/templates/rc-release-ann.ezt
===
--- tools/dist/templates/rc-release-ann.ezt (revision 1784199)
+++ tools/dist/templates/rc-release-ann.ezt (working copy)
@@ -3,9 +3,9 @@ Please choose the mirror closest to you by visitin
http://subversion.apache.org/download.cgi#[anchor]
-The SHA1 checksums are:
+The SHA-512 checksums are:
-[for sha1info][sha1info.sha1] [sha1info.filename]
+[for sha512info][sha512info.sha512] [sha512info.filename]
[end]
PGP Signatures are available at:
Index: tools/dist/templates/stable-release-ann.ezt
===
--- tools/dist/templates/stable-release-ann.ezt (revision 1784199)
+++ tools/dist/templates/stable-release-ann.ezt (working copy)
@@ -3,9 +3,9 @@ Please choose the mirror closest to you by visitin
http://subversion.apache.org/download.cgi#[anchor]
-The SHA1 checksums are:
+The SHA-512 checksums are:
-[for sha1info][sha1info.sha1] [sha1info.filename]
+[for sha512info][sha512info.sha512] [sha512info.filename]
[end]
PGP Signatures are available at:
Files with identical SHA1 breaks the repo
Earlier today, the first known SHA1 collision was presented: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html http://shattered.io/ It turns out that adding these two PDF files to a svn repository makes it impossible to checkout the repository properly if both files exist in the repo. This script demonstrates what happens: --- CUT #!/bin/sh if test -e repo -o -e wc1 -o -e wc2; then echo repo, wc1 or wc2 already exist >&2 exit 1 fi svnadmin create repo svn co file://$(pwd)/repo wc1 cd wc1 wget https://shattered.it/static/shattered-1.pdf wget https://shattered.it/static/shattered-2.pdf svn add *.pdf svn ci -m "Add files with identical SHA1" cd .. svn co file://$(pwd)/repo wc2 --- CUT This happens: $ ./runme Checked out revision 0. --2017-02-23 20:41:05-- https://shattered.it/static/shattered-1.pdf Resolving shattered.it (shattered.it)... 216.239.38.21, 216.239.36.21, 216.239.32.21, ... Connecting to shattered.it (shattered.it)|216.239.38.21|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 422435 (413K) [application/pdf] Saving to: ‘shattered-1.pdf’ shattered-1.pdf 100%[===>] 412.53K --.-KB/s in 0.04s 2017-02-23 20:41:05 (10.9 MB/s) - ‘shattered-1.pdf’ saved [422435/422435] --2017-02-23 20:41:05-- https://shattered.it/static/shattered-2.pdf Resolving shattered.it (shattered.it)... 216.239.38.21, 216.239.36.21, 216.239.32.21, ... Connecting to shattered.it (shattered.it)|216.239.38.21|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 422435 (413K) [application/pdf] Saving to: ‘shattered-2.pdf’ shattered-2.pdf 100%[===>] 412.53K --.-KB/s in 0.04s 2017-02-23 20:41:06 (9.03 MB/s) - ‘shattered-2.pdf’ saved [422435/422435] A (bin) shattered-1.pdf A (bin) shattered-2.pdf Adding (bin) shattered-1.pdf Adding (bin) shattered-2.pdf Transmitting file data .. Committed revision 1. Awc2/shattered-1.pdf svn: E200014: Checksum mismatch for '/home/sunny/src/git/svn-sha1/wc2/shattered-2.pdf': expected: 5bd9d8cabc46041579a311230539b8d1 actual: ee4aa52b139d925f8d8884402b0a750c $ Tested with svn-1.8.10, which is the default svn in Debian 8.7, newest stable. shattered-1.pdf is checked out, but not shattered-2.pdf. This is the only known SHA-1 collision at the moment, but Google will release the collision code in 90 days, so we can expect this not to last forever. Regards, Øyvind +-| Øyvind A. Holm - N 60.37604° E 5.9° |-+ | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc | | Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 | +| cb5c25a6-fa01-11e6-8cd8-db5caa6d21d3 |-+ signature.asc Description: PGP signature
Re: feature suggestion: adressing the repo relative to working copy url
Daniel Shahaf wrote: >Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +: >[...] >> >> But back to original topic: I could live with using '^./' as the >> general prefix for "current working copy folder relative addressing". >> >> so my 4 examples above would change to: >> >> ^./subpath subpath of the current working copy folder >> ^./../ parent >> ^./../path sibling >> ^./../../grand parent > >Okay. I see you changed ^../ to ^./../ . What would ^../ mean then? nothing 8-) Only ^/... and ^./... would be allowed. -- Lorenz
Re: feature suggestion: adressing the repo relative to working copy url
Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +: > Daniel Shahaf wrote: > >Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +: > >> Stefan Sperling wrote: > >> >From 'svn help ps': > >> > The URL may be a full URL or a relative URL starting with one of: > >> >../ to the parent directory of the extracted external > >> >^/ to the repository root > >> >/to the server root > >> >// to the URL scheme > >> > ^/../ to a sibling repository beneath the same SVNParentPath > >> > location > >> > >> I am aware of the svn:externals syntax, but in light of the fact that > >> ^/ was alread adopted, I thought it best to stick with the ^ > >> > >> If the cmomand line client accepts the ^ as the "translate the > >> following path to an URL" marker, then anything after it could be > >> interpreted as a normal path. > >> > >> ^/ repo root relative > >> ^/../name sibling repo > >> > >> ^subpath subpath of the current working copy folder > >> ^../ parent > >> ^../path sibling > >> ^../../grand parent > > > >If the first of these four were changed to require a ./ path component, > >we could repurpose the ^foo/ syntax to something else: > > > >^./subpathsubpath relative to URL of cwd > >^foo/ as defined by a --config-option=config:short-urls:foo=bar > > config option > >[...] > > the last is an independent idea for an additional feature, right? Partly. Implementation wise,, the "map of short names to URLs" needn't be implemented at the same time as the other ideas; those _are_ independent. However, at the UI level, both feature ideas touch on the same '"URL" space', so at that level they aren't independent. > 'foo' would be a shortcut for a base URL? > I think, without some sort of indicator, it looks to much like a path. > I would prefer to mark a shortcut explicitly as such. > No idea how though, another prefix? Perhaps '^:shortcut/" would do? > Maybe. :-) > > But back to original topic: I could live with using '^./' as the > general prefix for "current working copy folder relative addressing". > > so my 4 examples above would change to: > > ^./subpathsubpath of the current working copy folder > ^./../parent > ^./../pathsibling > ^./../../ grand parent Okay. I see you changed ^../ to ^./../ . What would ^../ mean then? Cheers, Daniel
Re: feature suggestion: adressing the repo relative to working copy url
Branko ?ibej wrote: >On 22.02.2017 17:42, Daniel Shahaf wrote: >> Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +: >>> Stefan Sperling wrote: >>> >From 'svn help ps': The URL may be a full URL or a relative URL starting with one of: ../ to the parent directory of the extracted external ^/ to the repository root /to the server root // to the URL scheme ^/../ to a sibling repository beneath the same SVNParentPath location >>> I am aware of the svn:externals syntax, but in light of the fact that >>> ^/ was alread adopted, I thought it best to stick with the ^ >>> >>> If the cmomand line client accepts the ^ as the "translate the >>> following path to an URL" marker, then anything after it could be >>> interpreted as a normal path. >>> >>> ^/ repo root relative >>> ^/../name sibling repo >>> >>> ^subpathsubpath of the current working copy folder >>> ^../parent >>> ^../pathsibling >>> ^../../ grand parent >> If the first of these four were changed to require a ./ path component, > >... then it would not be backward compatible with existing syntax. >[...] hm, to what existing syntax would "^./subpath" be in conflict with? -- Lorenz
Re: feature suggestion: adressing the repo relative to working copy url
Branko Čibej wrote on Thu, Feb 23, 2017 at 13:47:12 +0100: > On 22.02.2017 17:42, Daniel Shahaf wrote: > > Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +: > >> Stefan Sperling wrote: > >> >From 'svn help ps': > >>> The URL may be a full URL or a relative URL starting with one of: > >>>../ to the parent directory of the extracted external > >>>^/ to the repository root > >>>/to the server root > >>>// to the URL scheme > >>> ^/../ to a sibling repository beneath the same SVNParentPath > >>> location > >> I am aware of the svn:externals syntax, but in light of the fact that > >> ^/ was alread adopted, I thought it best to stick with the ^ > >> > >> If the cmomand line client accepts the ^ as the "translate the > >> following path to an URL" marker, then anything after it could be > >> interpreted as a normal path. > >> > >> ^/ repo root relative > >> ^/../name sibling repo > >> > >> ^subpath subpath of the current working copy folder > >> ^../ parent > >> ^../path sibling > >> ^../../grand parent > > If the first of these four were changed to require a ./ path component, > > ... then it would not be backward compatible with existing syntax. > My suggestion doesn't change the meaning of the released ^/foo syntax, only of the ^foo/ syntax [where "foo" doesn't begin with a slash] in Lorenz's proposal. Thus, it's backwards compatible. > > we could repurpose the ^foo/ syntax to something else: > > > > ^./subpathsubpath relative to URL of cwd > > ^foo/ as defined by a --config-option=config:short-urls:foo=bar > > config option > > Ah, a config option to enable mutually incompatible semantics to > short-url syntax! > > I'm assuming you're volunteering to personally solve any confusion that > causes on the users@ list and beyond, for the forseeable future. :) I'm personally volunteering to fly over to your place and explain on a whiteboard how this is backwards compatible. :-)
Re: Bug in "svnrdump" ?
Doug Robinson wrote: https://issues.apache.org/jira/browse/SVN-4672 Thanks, Doug, that's great. Let me know if you need me to drive it further; I'm assuming not. Bert wrote: That code is in the backing code for svn_ra_replay(), where it also applies to authz, not on the client. That makes sense. I believe both svnrdump and svnsync use this. I assumed both of them would support converting copies to adds... @Julian Foad Can we use svnsync in this scenario, or does that break in a similar way? ... but I haven't tested it. - Julian
Re: feature suggestion: adressing the repo relative to working copy url
On 22.02.2017 17:42, Daniel Shahaf wrote: > Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +: >> Stefan Sperling wrote: >> >From 'svn help ps': >>> The URL may be a full URL or a relative URL starting with one of: >>>../ to the parent directory of the extracted external >>>^/ to the repository root >>>/to the server root >>>// to the URL scheme >>> ^/../ to a sibling repository beneath the same SVNParentPath location >> I am aware of the svn:externals syntax, but in light of the fact that >> ^/ was alread adopted, I thought it best to stick with the ^ >> >> If the cmomand line client accepts the ^ as the "translate the >> following path to an URL" marker, then anything after it could be >> interpreted as a normal path. >> >> ^/ repo root relative >> ^/../namesibling repo >> >> ^subpath subpath of the current working copy folder >> ^../ parent >> ^../path sibling >> ^../../ grand parent > If the first of these four were changed to require a ./ path component, ... then it would not be backward compatible with existing syntax. > we could repurpose the ^foo/ syntax to something else: > > ^./subpathsubpath relative to URL of cwd > ^foo/ as defined by a --config-option=config:short-urls:foo=bar > config option Ah, a config option to enable mutually incompatible semantics to short-url syntax! I'm assuming you're volunteering to personally solve any confusion that causes on the users@ list and beyond, for the forseeable future. :) -- Brane
