Ben Collins <email@example.com> writes:
> On Fri, Apr 05, 2002 at 07:57:26PM +0100, Philip Martin wrote:
> > firstname.lastname@example.org writes:
> > > Make client application parse 'svn merge' args correctly. This is just a
> > > first run. Karl suggests that we extend the "PATH@REV" syntax to
> > > *all* subcommands that can use it (diff, copy, etc.) That will be my
> > > next changeset, if possible.
> > I haven't seen much discussion about this feature. There are 75 files
> > on my system that include an '@' character in their name. Those are
> > all system files, and I am unlikely to want to version them, but file
> > names including an '@' do occur. Several of the common locales include
> > an '@' character in their name.
> > Perhaps we should follow Clearcase and use '@@', if only because the
> > fewer special sequences that are in use in the world, the better.
> perforce uses "@". I think this can be easily handled by stating for the
> full name first, and then chop off the "@.*" if that full name doesn't
> exist. Then you have a problem with a file called "foo" and "foo@123", if
> you want to see rev 123 of "foo". We have problems no matter what
'stating for the full name first' will need to work for URLs as well,
possibly a round trip to the server? Having different behaviour for
working copy paths and URLs would seem to be a bad idea.
Since there are already standard files on my system that include a
single '@' in the name I feel we should use a different delimiter. If
we choose something as common as '@' we definitely need a way to allow
filenames containing the delimiter. Perhaps some sort of escape
sequence or perhaps simply a trailing delimiter e.g. assuming an '@'
delimiter the filename 'foo@123@' could be passed as 'foo@123@@'
representing a filename with no revision.
Perhaps all we need to do is to assume that given a filename foo@bar,
then if bar fails to parse as a revision then rather than returning
SVN_ERR_CL_ARG_PARSING_ERROR assume that the entire foo@bar is the
filename. This would certainly cover all the existing cases on my
system, but it might involve too much 'magic' to be sensible. Just as
working copy paths and URLs should have consistent behaviour I feel
the filenames 'fr_FR@euro' and 'fr_FR@head' should behave the same
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 5 22:17:07 2002