Philip Martin wrote on Fri, Feb 17, 2012 at 09:56:38 +0000:
> Daniel Shahaf <d...@daniel.shahaf.name> writes:
>
> > danie...@tigris.org wrote on Thu, Feb 16, 2012 at 17:00:07 -0800:
> >> ------- Additional comments from danie...@tigris.org Thu Feb 16 17:00:07
> >> -0800 2012 -------
> >> % ln -s foo bar
> >> % $svn add -q bar
> >> % $svn cat bar
> >> svn: E200009: '/home/daniel/src/svn/t1/bar' has no base revision until it
> >> is committed
> >> zsh: exit 1 $SVN cat bar
> >>
> >> By comparison,
> >> % $svn cat ../site/publish/faq.en.html
> >> link faq.html<no newline>
> >> %
> >>
> >> ------- Additional comments from danie...@tigris.org Thu Feb 16 17:12:43
> >> -0800 2012 -------
> >> It applies to any file, not just to symlinks.
> >
> > Sanity check please -- we do expect 'touch foo; svn add foo; svn cat
> > foo' to work, right?
>
> 1.7 is much like 1.6:
>
> svn: E200009: '/home/pm/sw/subversion/obj/wc/f' has no base revision until it
> is committed
>
> svn: Can't open file 'wc/.svn/text-base/f.svn-base': No such file or directory
>
> Note that 'svn ls' has the same behaviour.
>
> I suppose we could make them work. Perhaps it should involve a new
> symbolic revision 'WORKING@?
>
I'm not sure.
On the one hand, I'm the first to admit that consistency and KISS are
a good thing --- and "every non-URL target argument's peg revision
defaults to BASE" is an instance of those.
On the other hand... semantically, it's an added file; it does not
_have_ any other possible values for the peg revision, other than
WORKING --- so why would I have to specify it explicitly?
> $ svn cat file@WORKING
> $ svn ls dir -rWORKING
>
> How many other commands would be affected?
>
Some commands already assume @WORKING for added files:
% svn info bar
Schedule: add
% svn rm bar
svn: E195006: '/home/daniel/src/svn/t1/bar' has local modifications --
commit or revert them first
% $svn rm --force bar
D bar
% svn cp bar bar2
A bar2
But some others don't: 'blame', for example. (We have support for
blaming lines to rWORKING, but blaming an added file neither works
nor gives a "This invocation doesn't make sense" error.)
Other commands (which are repository-side by nature) may want to
continue contacting the repository, in order to run against a possible
bar@HEAD (which would cause an add/add tree conflict at the next
update): 'lock' and 'log', for example.
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
