On Friday 16 November 2012 04:41 PM, Neels J Hofmeyr wrote:
> Hi Vijay,
>
> I gave that patch a spin (after all I was the one who brought
> --include-externals upon us), and found stuff. Using current trunk + your
> patch v3.
I was looking at your code 'commit --include-externals' before working
on this patch. Thanks for your detailed explanation of the issues and
shell script! ;)
>
> BTW, I'm sorry to have to drag this patch submission out; countless times I
> myself tried to just quickly fix a small externals quirk and it ended up
> sticking to my fingers for weeks. Don't give up! ;)
Sure. I will never give up!
>
> There's a small thing and a more complex one.
>
> (1) 'svn list' normally only lists the current dir level unless -R is
> supplied. So --include-externals should actually only print the externals
> dirnames, and step into them only with -R also supplied. Right?
>
> That was the small thing.
Yes. 'svn ls' will run with '--depth=immediates' by default. But I have
few questions regarding this approach.
1. what should we do for "svn ls --include-externals --depth=files" ?
Listing only file externals?
Not sure how complex it will be to implement it on top of the current patch.
2. If we are printing the externals dirnames alone, how we are going to
list the item in verbose mode? How can we get the revision number,
author, date and size for the particular external's dirname?
If we do like as follows, won't it be easy to understand?
Copycatting from my initial proposal of this feature[1],
$ svn list --include-externals
The current working copy directory and all externals(including externals
inside of externals) under cwd will be listed with depth 'immediates'.
$ svn list --depth=infinity --include-externals
The current working copy directory and all externals(including externals
inside of externals) under cwd will be listed with depth 'infinity'.
It works the same way as above for 'svn list --depth=files
--include-externals'.
>
>
> (2)
> I'm comparing
> svn list --include-externals
> with
> svn list ./external-target-dir/
>
> After removing and committing a file inside an external, there is a
> difference between above invocations:
>
> (test script also attached)
> [[[
> # prepare an external dir...
> mkdir a
> echo a > a/file
> echo b > b
> svn add a b
> svn propset svn:externals "^/a x1" .
> svn ci -mm
> svn up
>
> # remove a file and commit inside external dir
> svn rm x1/file
> svn ci -mm x1
>
> svn list --include-externals
> # a/
> # b
> # Listing external 'x1' defined on 'file:///tmp/trunk.qLP/repos':
>
> svn list x1
> # file
>
> ## ^ difference: 'list x1' still shows 'file'
>
> # comparison: 'list' behavior when no external is involved
> # a normal deleted file is still shown, until next update.
> svn rm b
> svn ci -mm
> svn list
> # a/
> # b
> ]]]
> (After the next update, all invocations don't show the deleted file anymore,
> obviously.)
>
> I expected 'list --include-externals' to act exactly like 'svn list x1/',
> but there is a slight difference. I suspect that 'svn list x1/' takes
> advantage of the WC at x1/ already present locally, and that 'svn list
> --include-externals' goes directly to the repos URL. Is that right?
I assume the following when you say, "'svn list x1/' takes
advantage of the WC at x1/ already present locally".
'svn list' will always use the repository URL even if the list target is
a working copy path. The file/directory entries under list target will
always be fetched from repository URL using svn_ra_get_dir2().
But what makes the command 'svn list x1/' to list a deleted file?
Revision and peg-revision of the WC path being listed. If revision and
peg-revision are not specified, they default to
#svn_opt_revision_working for WC targets and #svn_opt_revision_head for
URLs.
> Maybe 'svn list --include-externals' should limit to listing strictly only
> those externals currently checked out (unless the target itself is a URL).
> I.e. if the target is a working copy, traverse the WC for checked out
> externals and maybe even feed the local external WC paths as explicit
> targets to svn_client_list3() or something ... ?
But should we make 'svn list' to be WC dependent while listing externals?
[1] http://svn.haxx.se/dev/archive-2012-10/0381.shtml
Thanks & Regards,
Vijayaguru
> Good speed!
> ~Neels
>
Received on 2012-11-20 11:58:02 CET