Re: SVN keyword replacement

[Vincent Lefevre]

On 2019-02-19 20:37:01 +, Scott Bloom wrote:
> Thanks.. That is exactly what Im looking for!

Even if this is implemented, there's an issue with all these keywords
with path/URL information in them: the expanded path is the one of the
revision that last changed the file, not the current one! For instance,
if the file is in a directory that has been renamed and the file hasn't
changed since, then the expanded path will become obsolete (mentioning
the old directory name).

For instance, after a "svn mv dir newdir" and commit:

$ cat newdir/file
$PathRev: dir/file, r2 $
$ svn pl -v newdir/file
Properties on 'newdir/file':
  svn:keywords
PathRev=%P,%_r%r
$ svn info newdir/file
Path: newdir/file
Name: file
Working Copy Root Path: /home/vlefevre/tmp/svntest/wc
URL: file:///home/vlefevre/tmp/svntest/foo/newdir/file
Relative URL: ^/newdir/file
Repository Root: file:///home/vlefevre/tmp/svntest/foo
Repository UUID: c461bb2a-7775-4e63-8d8c-e8e280081214
Revision: 3
Node Kind: file
Schedule: normal
Last Changed Author: vlefevre
Last Changed Rev: 2
[...]

BTW, the documentation in
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
is incorrect:

  %P
The file's path, relative to the repository root.

should be

  %P
The file's path of the revision given by %r, relative to the
repository root.

AFAIK, "of the revision given by %r" applies to all format codes.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: SVN keyword replacement

[Daniel Shahaf]

Mark Phippard wrote on Tue, 19 Feb 2019 20:53 +00:00:
> It ought to cover everything. If this looks like it is going to take a 
> considerable amount of your time then you might want to post what you 
> plan to do on the dev@ mailing list. There is no point spending time on 
> this if someone plans to veto it. As I noted, there are reasons some 
> might object to this idea. If it is a fairly quick patch then you might 
> as well let the patch show what you have in mind.

You probably want to use one of the svn_*_skip_ancestor() functions in
svn_dirent_uri.h.  You can look at 'svn info' for how to compute the wc
root path, if it isn't already available.

That said, I don't see anything preventing us from specifying a boolean
svn:x-branchroot nodeprop in 1.12.  We don't have to nail down the API,
or to add subcommands, or anything else; we can just specify it and see
what the ecosystem comes up with... though we _could_, say, introduce
an $X-branchrootrelativeurl$ keyword alongside it.

The X- in the names is to make them "experimental", i.e., covered by limited
compatibility promises.  With our recent shift to LTS and non-LTS releases,
we can start using non-LTS releases as vehicles for getting wider feedback
on ideas, by shipping those ideas as "experimental".

Cheers,

Daniel

Re: SVN keyword replacement

[Mark Phippard]

On Tue, Feb 19, 2019 at 3:37 PM Scott Bloom  wrote:

> Thanks.. That is exactly what Im looking for!
>
>
>
> Ill contact you off list on contribution procedures if that’s ok.
>

More info then you could ever hope for is available here:

https://subversion.apache.org/docs/community-guide/

It ought to cover everything.  If this looks like it is going to take a
considerable amount of your time then you might want to post what you plan
to do on the dev@ mailing list. There is no point spending time on this if
someone plans to veto it. As I noted, there are reasons some might object
to this idea. If it is a fairly quick patch then you might as well let the
patch show what you have in mind.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Thanks.. That is exactly what Im looking for!

Ill contact you off list on contribution procedures if that’s ok.

Scott
From: Mark Phippard 
Sent: Tuesday, February 19, 2019 10:30
To: Scott Bloom 
Cc: Pavel Lyalyakin ; users@subversion.apache.org
Subject: Re: SVN keyword replacement

On Tue, Feb 19, 2019 at 1:13 PM Mark Phippard 
mailto:markp...@gmail.com>> wrote:
On Tue, Feb 19, 2019 at 1:08 PM Scott Bloom 
mailto:sc...@towel42.com>> wrote:
Unfortunately %P still includes branch directories….

Yes, it is repository relative. That is the best you are going to get out of 
Subversion.

Subversion does not really have branches or tags.  It has paths (folders and 
files). Branches and tags are just a convention of how you use those paths.  
Even defining a syntax to lop off some part of the %P would be pretty difficult 
when you consider you might have "root" paths of all different depths:

/trunk
/branches/1.8.x
/branches/releases/1.8.x
/branches/features/joe/feature-1
/tags/release/1.8.9
/tags/1.8.9

etc.

Short of some major change in SVN to let you mark the root of your tree there 
probably will not ever be a way to do any better than what %P gives you.

One idea that occurred to me would be adding a new value of %W that is similar 
to %P except the path is relative to the root of the working copy.  Assuming 
that is generally the root of your project, such as /trunk this would give the 
sort of path you desire.  I do not know if there would be any general 
objections to a value that varied so easily based on something as arbitrary as 
the working copy root though.  That said, given that keywords are only expanded 
in the working copy it does not seem unreasonable to hand this decision over to 
the user.
M
If you want to work on a contribution, I would perhaps consider something like 
that.  Here is the change that added this feature:

http://svn.apache.org/viewvc?view=revision&revision=1466570

There is also a long tortured history on this topic and feature:

https://issues.apache.org/jira/browse/SVN-890

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: SVN keyword replacement

[Mark Phippard]

On Tue, Feb 19, 2019 at 2:09 PM Daniel Shahaf 
wrote:

> Mark Phippard wrote on Tue, 19 Feb 2019 18:30 +00:00:
> > One idea that occurred to me would be adding a new value of %W that is
> > similar to %P except the path is relative to the root of the working
> > copy. Assuming that is generally the root of your project, such as
> > /trunk this would give the sort of path you desire. I do not know if
> > there would be any general objections to a value that varied so easily
> > based on something as arbitrary as the working copy root though. That
> > said, given that keywords are only expanded in the working copy it does
> > not seem unreasonable to hand this decision over to the user.
>
> I'm not a fan of this.


Shrug. I've never seen the point of the entire feature and do not have any
plans to ever use it for any keyword.

  The working copy root can be either above or
> below the usual/customary level for creating the tag: when rolling a
> Subversion release my wcroot may be ^/subversion,
> ^/subversion/branches/1.11.x, or
> ^/subversion/branches/1.11.x/tools/dist.  Ultimately, it's a random
> environmental value, like ~/.subversion/config settings.  Any workflow
> that diffs these files using anything other 'svn diff' — for example,
> diff(1)
> or rsync — is going to run into the differences.  (For example, our release
>

I tend to think "so what". All that means is that we would not be using
this keyword just as we do not use the vast majority of them. We barely use
keywords and do not use custom keywords at all:

$ svn pg -R svn:keywords .
INSTALL - LastChangedDate
README - LastChangedDate
contrib/cgi/mirror_dir_through_svn.cgi - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/client-side/asvn - HeadURL LastChangedBy LastChangedDate
LastChangedRevision Id
contrib/client-side/diff-wrap.sh - HeadURL LastChangedBy LastChangedDate
LastChangedRevision Id
contrib/client-side/emacs/psvn.el - Id
contrib/client-side/svn-merge-vendor.py - HeadURL Id LastChangedBy
LastChangedDate LastChangedRevision
contrib/client-side/svn_all_diffs.pl - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/client-side/svn_apply_autoprops.py - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/client-side/svn_export_empty_files.py - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/client-side/svn_load_dirs/LICENSE_AFL3.txt - HeadURL Id
LastChangedBy LastChangedDate LastChangedRevision
contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in - HeadURL
LastChangedBy LastChangedDate LastChangedRevision
contrib/client-side/svnmerge/svnmerge-migrate-history-remotely.py - HeadURL
Author Date Rev
contrib/client-side/svnmerge/svnmerge-migrate-history.py - HeadURL
LastChangedBy LastChangedDate LastChangedRevision Id
contrib/client-side/svnmerge/svnmerge.README - HeadURL LastChangedBy
LastChangedDate LastChangedRevision Id
contrib/client-side/svnmerge/svnmerge.py - HeadURL LastChangedBy
LastChangedDate LastChangedRevision Id
contrib/client-side/svnmerge/svnmerge.sh - HeadURL LastChangedBy
LastChangedDate LastChangedRevision Id
contrib/hook-scripts/case-insensitive.py - HeadURL Id LastChangedBy
LastChangedDate LastChangedRevision
contrib/hook-scripts/commit-email.pl.in - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/hook-scripts/detect-merge-conflicts.sh - HeadURL LastChangedBy
LastChangedDate LastChangedRevision Id
contrib/hook-scripts/svn-keyword-check.pl - HeadURL LastChangedBy
LastChangedDate LastChangedRevision
contrib/server-side/add-needs-lock.py - HeadURL LastChangedBy
LastChangedDate LastChangedRevision Id
contrib/server-side/fsfsfixer/fixer/fix-rev.py - Date Revision URL
notes/api-errata/1.10/ra001.txt - Id
notes/api-errata/1.10/svnserve001.txt - Id
notes/api-errata/1.7/ra001.txt - Id
notes/api-errata/1.7/wc001.txt - Id
notes/api-errata/1.7/wc002.txt - Id
notes/api-errata/1.7/wc003.txt - Id
notes/api-errata/1.7/wc004.txt - Id
notes/api-errata/1.7/wc005.txt - Id
notes/api-errata/1.7/wc006.txt - Id
notes/api-errata/1.7/wc007.txt - Id
notes/api-errata/1.8/fs001.txt - Id
notes/api-errata/1.9/fs001.txt - Id
notes/hold - Date
notes/merge-tracking/design.html - date
notes/merge-tracking/func-spec.html - date
notes/merge-tracking/requirements.html - date
notes/repos_upgrade_HOWTO - LastChangedDate
notes/variance-adjusted-patching.html - date
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c - Id
subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.h - Id
subversion/include/private/svn_error_private.h - HeadURL Id LastChangedBy
LastChangedDate LastChangedRevision
tools/backup/hot-backup.py.in - HeadURL LastChangedBy LastChangedDate
LastChangedRevision Id
tools/dev/gen_junit_report.py - Id
tools/dev/iz/find-fix.py - Rev
tools/dev/which-error.py - HeadURL LastChangedDate LastChangedBy
LastChangedRevision
tools/examples/svnlook.py - URL Date Revision
tools/hook-scripts/commit-access-control.cfg.example - Id
tools/hook-scripts/commit-access-contro

Re: SVN keyword replacement

[Daniel Shahaf]

Mark Phippard wrote on Tue, 19 Feb 2019 18:30 +00:00:
> One idea that occurred to me would be adding a new value of %W that is 
> similar to %P except the path is relative to the root of the working 
> copy. Assuming that is generally the root of your project, such as 
> /trunk this would give the sort of path you desire. I do not know if 
> there would be any general objections to a value that varied so easily 
> based on something as arbitrary as the working copy root though. That 
> said, given that keywords are only expanded in the working copy it does 
> not seem unreasonable to hand this decision over to the user.

I'm not a fan of this.  The working copy root can be either above or
below the usual/customary level for creating the tag: when rolling a
Subversion release my wcroot may be ^/subversion,
^/subversion/branches/1.11.x, or
^/subversion/branches/1.11.x/tools/dist.  Ultimately, it's a random
environmental value, like ~/.subversion/config settings.  Any workflow
that diffs these files using anything other 'svn diff' — for example, diff(1)
or rsync — is going to run into the differences.  (For example, our release

There were discussions of this back in 2011/2012, for example, about
recursing upwards to the nearest path-wise ancestor that has an
svn:branchroot=yes property set, or the nearest path-wise ancestor that
is a copyfrom-wise descendant of trunk (i.e., has the same node-id as
trunk's noderev). [1]  This has the advantage that the keyword will be
expanded in the same way in all working copies, and even in
mod_dav_svn [2].

Cheers,

Daniel

https://svn.haxx.se/dev/archive-2012-07/0168.shtml
(message-id 4ce3f25b-e509-4743-b839-7d60c1797...@snakebite.org)

[2] https://subversion.apache.org/docs/release-notes/1.8#davkeywordexpansion
(we need a search engine for our release notes...)

Re: SVN keyword replacement

[Mark Phippard]

On Tue, Feb 19, 2019 at 1:13 PM Mark Phippard  wrote:

> On Tue, Feb 19, 2019 at 1:08 PM Scott Bloom  wrote:
>
>> Unfortunately %P still includes branch directories….
>>
>> 
>>
>>
> Yes, it is repository relative. That is the best you are going to get out
> of Subversion.
>
> Subversion does not really have branches or tags.  It has paths (folders
> and files). Branches and tags are just a convention of how you use those
> paths.  Even defining a syntax to lop off some part of the %P would be
> pretty difficult when you consider you might have "root" paths of all
> different depths:
>
> /trunk
> /branches/1.8.x
> /branches/releases/1.8.x
> /branches/features/joe/feature-1
> /tags/release/1.8.9
> /tags/1.8.9
>
> etc.
>
> Short of some major change in SVN to let you mark the root of your tree
> there probably will not ever be a way to do any better than what %P gives
> you.
>

One idea that occurred to me would be adding a new value of %W that is
similar to %P except the path is relative to the root of the working copy.
Assuming that is generally the root of your project, such as /trunk this
would give the sort of path you desire.  I do not know if there would be
any general objections to a value that varied so easily based on something
as arbitrary as the working copy root though.  That said, given that
keywords are only expanded in the working copy it does not seem
unreasonable to hand this decision over to the user.

If you want to work on a contribution, I would perhaps consider something
like that.  Here is the change that added this feature:

http://svn.apache.org/viewvc?view=revision&revision=1466570

There is also a long tortured history on this topic and feature:

https://issues.apache.org/jira/browse/SVN-890

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Appreciate the feedback.. I understand the “tags vs branches vs folders” issue… 
 I was just hoping.

Question, is it possible, to add a “regex” style custom keyword?  I would be 
willing to volunteer to implement it.
So maybe an automated system could figure this out, using other custom file 
attributes?

Scott
From: Mark Phippard 
Sent: Tuesday, February 19, 2019 10:13
To: Scott Bloom 
Cc: Pavel Lyalyakin ; users@subversion.apache.org
Subject: Re: SVN keyword replacement

On Tue, Feb 19, 2019 at 1:08 PM Scott Bloom 
mailto:sc...@towel42.com>> wrote:
Unfortunately %P still includes branch directories….

Yes, it is repository relative. That is the best you are going to get out of 
Subversion.

Subversion does not really have branches or tags.  It has paths (folders and 
files). Branches and tags are just a convention of how you use those paths.  
Even defining a syntax to lop off some part of the %P would be pretty difficult 
when you consider you might have "root" paths of all different depths:

/trunk
/branches/1.8.x
/branches/releases/1.8.x
/branches/features/joe/feature-1
/tags/release/1.8.9
/tags/1.8.9

etc.

Short of some major change in SVN to let you mark the root of your tree there 
probably will not ever be a way to do any better than what %P gives you.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: SVN keyword replacement

[Mark Phippard]

On Tue, Feb 19, 2019 at 1:08 PM Scott Bloom  wrote:

> Unfortunately %P still includes branch directories….
>
> 
>
>
Yes, it is repository relative. That is the best you are going to get out
of Subversion.

Subversion does not really have branches or tags.  It has paths (folders
and files). Branches and tags are just a convention of how you use those
paths.  Even defining a syntax to lop off some part of the %P would be
pretty difficult when you consider you might have "root" paths of all
different depths:

/trunk
/branches/1.8.x
/branches/releases/1.8.x
/branches/features/joe/feature-1
/tags/release/1.8.9
/tags/1.8.9

etc.

Short of some major change in SVN to let you mark the root of your tree
there probably will not ever be a way to do any better than what %P gives
you.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Unfortunately %P still includes branch directories….

Scott

From: Scott Bloom 
Sent: Tuesday, February 19, 2019 10:05
To: Scott Bloom ; Mark Phippard ; Pavel 
Lyalyakin 
Cc: users@subversion.apache.org
Subject: RE: SVN keyword replacement

Just a note..

the latest PDF/Web pages for SVN don’t have this information.

Scott


From: Scott Bloom mailto:sc...@towel42.com>>
Sent: Tuesday, February 19, 2019 10:04
To: Mark Phippard mailto:markp...@gmail.com>>; Pavel 
Lyalyakin mailto:pavel.lyalya...@visualsvn.com>>
Cc: users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: RE: SVN keyword replacement

Mark, This looks like its exactly what Im looking for!

Thanks

Scott

From: Mark Phippard mailto:markp...@gmail.com>>
Sent: Tuesday, February 19, 2019 10:01
To: Pavel Lyalyakin 
mailto:pavel.lyalya...@visualsvn.com>>
Cc: Scott Bloom mailto:sc...@towel42.com>>; 
users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Re: SVN keyword replacement

On Tue, Feb 19, 2019 at 12:55 PM Pavel Lyalyakin 
mailto:pavel.lyalya...@visualsvn.com>> wrote:
Hello Scott,

On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom 
mailto:sc...@towel42.com>> wrote:
>
> Our repository currently uses $HeadURL, and it works as advertised.
>
> However, I would prefer just the file from ^, this way if there is a branch, 
> and a switch, everyfile wont have to be rebuilt.
>
> The redbooks lists nothing like this, but Im hoping it’s a documentation issue
>
> Scott

Could you please show some examples of the desired result? How do you
use the $HeadURL keyword now? Do you want to make $HeadURL show
contents of this file? What '^' file are you asking about?

I assume by ^ he means it the same way that SVN can use this when specifying a 
URL within the working copy. IOW, he wants the repository-relative path of the 
file not the complete URL.

As long as you are using SVN 1.8 or later you can now define custom keywords.  
See:  https://subversion.apache.org/docs/release-notes/1.8#custom-keywords and 
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

It looks like %P is the value you would want to use.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Just a note..

the latest PDF/Web pages for SVN don’t have this information.

Scott


From: Scott Bloom 
Sent: Tuesday, February 19, 2019 10:04
To: Mark Phippard ; Pavel Lyalyakin 

Cc: users@subversion.apache.org
Subject: RE: SVN keyword replacement

Mark, This looks like its exactly what Im looking for!

Thanks

Scott

From: Mark Phippard mailto:markp...@gmail.com>>
Sent: Tuesday, February 19, 2019 10:01
To: Pavel Lyalyakin 
mailto:pavel.lyalya...@visualsvn.com>>
Cc: Scott Bloom mailto:sc...@towel42.com>>; 
users@subversion.apache.org<mailto:users@subversion.apache.org>
Subject: Re: SVN keyword replacement

On Tue, Feb 19, 2019 at 12:55 PM Pavel Lyalyakin 
mailto:pavel.lyalya...@visualsvn.com>> wrote:
Hello Scott,

On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom 
mailto:sc...@towel42.com>> wrote:
>
> Our repository currently uses $HeadURL, and it works as advertised.
>
> However, I would prefer just the file from ^, this way if there is a branch, 
> and a switch, everyfile wont have to be rebuilt.
>
> The redbooks lists nothing like this, but Im hoping it’s a documentation issue
>
> Scott

Could you please show some examples of the desired result? How do you
use the $HeadURL keyword now? Do you want to make $HeadURL show
contents of this file? What '^' file are you asking about?

I assume by ^ he means it the same way that SVN can use this when specifying a 
URL within the working copy. IOW, he wants the repository-relative path of the 
file not the complete URL.

As long as you are using SVN 1.8 or later you can now define custom keywords.  
See:  https://subversion.apache.org/docs/release-notes/1.8#custom-keywords and 
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

It looks like %P is the value you would want to use.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Mark, This looks like its exactly what Im looking for!

Thanks

Scott


From: Mark Phippard 
Sent: Tuesday, February 19, 2019 10:01
To: Pavel Lyalyakin 
Cc: Scott Bloom ; users@subversion.apache.org
Subject: Re: SVN keyword replacement

On Tue, Feb 19, 2019 at 12:55 PM Pavel Lyalyakin 
mailto:pavel.lyalya...@visualsvn.com>> wrote:
Hello Scott,

On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom 
mailto:sc...@towel42.com>> wrote:
>
> Our repository currently uses $HeadURL, and it works as advertised.
>
> However, I would prefer just the file from ^, this way if there is a branch, 
> and a switch, everyfile wont have to be rebuilt.
>
> The redbooks lists nothing like this, but Im hoping it’s a documentation issue
>
> Scott

Could you please show some examples of the desired result? How do you
use the $HeadURL keyword now? Do you want to make $HeadURL show
contents of this file? What '^' file are you asking about?

I assume by ^ he means it the same way that SVN can use this when specifying a 
URL within the working copy. IOW, he wants the repository-relative path of the 
file not the complete URL.

As long as you are using SVN 1.8 or later you can now define custom keywords.  
See:  https://subversion.apache.org/docs/release-notes/1.8#custom-keywords and 
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

It looks like %P is the value you would want to use.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN keyword replacement

[Scott Bloom]

Thanks for the response!

In our C++ files, we use the following in our copyright header

/*

$Author$ - $Revision$ - $Date$
$HeadURL$

*/

Which gets replaced with the appropriate data.

$HeadURL$ gets substituted with

$HeadURL: http://svnsvrpath/trunk/dir1/dir2/filename.cpp


The problem is, if I do a svn cp &  switch for a branch 
svn cp ^/trunk ^/branches/workbranch/
svn switch ^/branches/workbranch

the file gets updated (every file, every header etc) to
$HeadURL: http://svnsvrpath/branches/workbranch/dir1/dir2/filename.cpp

What I would prefer
$HeadURL: ^/dir1/dir2/filename.cpp

This way, I can see where the file is located in the repository, but on a svn 
branch, the file doesn’t change

Does this make sense?

Thanks again,
Scott



-Original Message-
From: Pavel Lyalyakin  
Sent: Tuesday, February 19, 2019 09:55
To: Scott Bloom 
Cc: users@subversion.apache.org
Subject: Re: SVN keyword replacement

Hello Scott,

On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom  wrote:
>
> Our repository currently uses $HeadURL, and it works as advertised.
>
> However, I would prefer just the file from ^, this way if there is a branch, 
> and a switch, everyfile wont have to be rebuilt.
>
> The redbooks lists nothing like this, but Im hoping it’s a 
> documentation issue
>
> Scott

Could you please show some examples of the desired result? How do you use the 
$HeadURL keyword now? Do you want to make $HeadURL show contents of this file? 
What '^' file are you asking about?


--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: SVN keyword replacement

[Mark Phippard]

On Tue, Feb 19, 2019 at 12:55 PM Pavel Lyalyakin <
pavel.lyalya...@visualsvn.com> wrote:

> Hello Scott,
>
> On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom  wrote:
> >
> > Our repository currently uses $HeadURL, and it works as advertised.
> >
> > However, I would prefer just the file from ^, this way if there is a
> branch, and a switch, everyfile wont have to be rebuilt.
> >
> > The redbooks lists nothing like this, but Im hoping it’s a documentation
> issue
> >
> > Scott
>
> Could you please show some examples of the desired result? How do you
> use the $HeadURL keyword now? Do you want to make $HeadURL show
> contents of this file? What '^' file are you asking about?
>

I assume by ^ he means it the same way that SVN can use this when
specifying a URL within the working copy. IOW, he wants the
repository-relative path of the file not the complete URL.

As long as you are using SVN 1.8 or later you can now define custom
keywords.  See:
https://subversion.apache.org/docs/release-notes/1.8#custom-keywords and
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html

It looks like %P is the value you would want to use.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: SVN keyword replacement

[Pavel Lyalyakin]

Hello Scott,

On Tue, Feb 19, 2019 at 8:41 PM Scott Bloom  wrote:
>
> Our repository currently uses $HeadURL, and it works as advertised.
>
> However, I would prefer just the file from ^, this way if there is a branch, 
> and a switch, everyfile wont have to be rebuilt.
>
> The redbooks lists nothing like this, but Im hoping it’s a documentation issue
>
> Scott

Could you please show some examples of the desired result? How do you
use the $HeadURL keyword now? Do you want to make $HeadURL show
contents of this file? What '^' file are you asking about?


--
With best regards,
Pavel Lyalyakin
VisualSVN Team