Issue #16 Use JCR context for checkout#17
Conversation
For the other commands filesystem context is retained.
alexkli
left a comment
There was a problem hiding this comment.
Thanks for the patch! A few comments inline.
| function jcr_to_filesystem() { | ||
| local jcrPath=$1 | ||
| # Handle namespaces and a default empty one | ||
| echo ${jcrPath} | sed -e 's#\/\([^:]*\):#/_\1_#g' | sed -e 's#/:#/#g' |
There was a problem hiding this comment.
- sed
AFAICS, it seems it could match /path/jcr for input /path/jcr:content which we wouldn't want.
It probably should include the slash in the not-match array [^:\/] so that it does not go beyond a / when it searches for the next :.
- sed
How did you come across /:? Isn't that an input error that we should probably throw on? Or is it a special case cleanup of the 1. sed and if yes, shouldn't that be fixed in the first one?
While we are at it, we need to double-escape a leading _ IIUC. This is the logic we have to copy here – jcr (repo) to filesystem (platform): https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/util/PlatformNameFormat.java#L66-L114
Note the StringBuffer initialized with a leading _.
There was a problem hiding this comment.
BTW, we could apply the regexp approach to filesystem_to_jcr() as well instead of the hardcoded list. The underscore escaping can only happen for the first char after a slash, and if it's /path/__something then it shall become /path/_something IIUC:
There was a problem hiding this comment.
@alexkli: Thanks for thorough review! It makes sense to reiterate on this and fix/simplify the code. At least it was working for me. Let me find some time this week to fix this and I hope we can finish it soon.
My replies (but not code yet fixed):
- Right, regexp usually takes the longest string that is able to match so we need to include both boundaries:
/&:instead of just: /:is a special allowed case of a default namespace (I briefly reviewed JCR standard looking for so called XML namespace prefix). The problem I see here is that we will end up with:__propertyNamewhich is not exactly the same aspropertyName. We probably should review how Vault deals with such things under the hood. I'm okay to drop this if Vault manages double_.- Probably because of
_escape__will be treated as_in that case so we cannot drop2.
| humanFilter=$fsFilter/* | ||
| else | ||
| humanFilter=$filter | ||
| humanFilter=$jcrFilter |
There was a problem hiding this comment.
I wonder if it now makes more sense to always print the filesystem path upon put and the jcr path upon get (see messages below). AFAICS, the path exists in the checkout case, so it would print the filesystem path here, whereas in later gets it would print the jcr path, a bit confusing. wdyt?
| # get dirname and basename for each | ||
| pathDirname=${path%/*} | ||
| filterDirname=${filter%/*} | ||
| filterDirname=${fsFilter%/*} |
There was a problem hiding this comment.
Might want to rename this to fsFilterDirname for consistent naming.
| filterDirname=${fsFilter%/*} | ||
| pathBasename=${path##*/} | ||
| filterBasename=${filter##*/} | ||
| filterBasename=${fsFilter##*/} |
There was a problem hiding this comment.
Might want to rename this to fsFilterBasename for consistent naming.
| filter=${path##*/jcr_root} | ||
|
|
||
| # Deducting JCR path | ||
| fsFilter="${filter}" |
There was a problem hiding this comment.
$filter isn't used anymore later, so I suggest to merge the lines above and just have
fsFilter=${path##*/jcr_root}
and below use
jcrFilter=$(filesystem_to_jcr "${fsFilter}")
which should make it more obvious what's converted.
| # path argument must be a jcr path | ||
| filter="$path" | ||
| jcrFilter="$path" | ||
| fsFilter=$(jcr_to_filesystem "$path") |
There was a problem hiding this comment.
Suggest to do fsFilter=$(jcr_to_filesystem "$jcrFilter") so it's a little more obvious.
|
BTW: apart from the above comments, I haven't check yet the script with shellcheck tool. WDYT to review it via that tool or it was already done in the past for I would feel personally safer applying this PR after reviewing additionally shellcheck report on top of all your suggestions. |
|
Haven't run shellcheck or the like, curious to see what it will say 😄 |
|
@alexkli I'm committing to fix most of them :-D This is the output from: |
|
Ok, but I would suggest to do the shellcheck work in a separate PR, since it will affect the whole script, and shouldn't be mixed with the changes for this issue. |
For the other commands filesystem context is retained.
As I proposed in issue #16 I was able to prepare and test a PR.