You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Grant Edwards <gr...@gmail.com> on 2016/04/26 01:02:54 UTC
Questions about --pin-externals option
A couple questions regarding "svn copy --pin-externals":
1) I thought I saw that when the --pin-externals option was being
developed it handled things differently when the destination was a
tag verses a branch.
IIRC, copy --pin-externals to a "tag" destination just pinned the
revision to the current one (leaving the path the same), but if the
destination was a "branch" and the source was relative, it would
leave the version floating and change the path so it too pointed to
a branch (or something like that).
Did the branch handling stuff get dropped?
2) Are there server-side version dependancies for use of the
--pin-externals option? Or will it work with any server version?
Where does one find documentation for 1.9 versions (the book only
covers versions up to 1.8)?
--
Grant Edwards grant.b.edwards Yow! I didn't order any
at WOO-WOO ... Maybe a YUBBA
gmail.com ... But no WOO-WOO!
Re: Questions about --pin-externals option
Posted by Branko Čibej <br...@apache.org>.
On 26.04.2016 01:27, Stefan wrote:
> Hi Edwards,
>> A couple questions regarding "svn copy --pin-externals":
>>
>> 1) I thought I saw that when the --pin-externals option was being
>> developed it handled things differently when the destination was a
>> tag verses a branch.
>>
>> IIRC, copy --pin-externals to a "tag" destination just pinned the
>> revision to the current one (leaving the path the same), but if the
>> destination was a "branch" and the source was relative, it would
>> leave the version floating and change the path so it too pointed to
>> a branch (or something like that).
>>
>> Did the branch handling stuff get dropped?
> That would be news to me. As far as I'm aware SVN does not treat
> tags/branches special in any case.
> To keep externals "floating" simply use externals without pinning them
> to a certain revision, or am I getting your question wrong?
There is no difference between "branches" and "tags." The
--pin-externals option applies to the 'svn copy' command, there's no
extra magic beyond that.
>> 2) Are there server-side version dependancies for use of the
>> --pin-externals option? Or will it work with any server version?
> This client-side feature works with any server but requires a client
> >= 1.9.
> Note that the feature to specify externals with peg revisions was
> actually added in 1.5 already [1].
> That said, if you use that feature all clients which access the
> repository should be >= 1.5 to understand the syntax correctly.
> 1.9 only added that command line option to simplify working with
> externals.
That's not the case at all. The old externals format prior to 1.5 did
have a revision parameter that was in fact interpreted as a peg
revision. 'svn copy --pin-externals' detects the format of the externals
reference does not change it even when adding a revision specifier.
Clients older than 1.5 will continue to work with branches and tags that
were created with the --pin-externals option.
-- Brane
Re: Questions about --pin-externals option
Posted by Grant Edwards <gr...@gmail.com>.
On 2016-04-26, Branko Čibej <br...@apache.org> wrote:
> Externals /are/ nested working copies as far as the client is concerned.
> Sure nothing prevents you from using nested working copies that aren't
> tracked as externals, but you'll have to invent your own tooling for
> checkouts, updates, commits, etc.
Yea, I can't really imagine any advantage to the "non-externals"
method except you don't have the opportunaty to accidentally tag a
version with an externals link pointing to wherever@HEAD and then
check it out later and build something incorrectly without realizing
what happened.
Both approches require people to follow some new workflow rules, but
the externals route seems to require fewer.
--
Grant Edwards grant.b.edwards Yow! Didn't I buy a 1951
at Packard from you last March
gmail.com in Cairo?
Re: Questions about --pin-externals option
Posted by Branko Čibej <br...@apache.org>.
On 26.04.2016 20:32, Grant Edwards wrote:
> On 2016-04-26, Branko Čibej <br...@apache.org> wrote:
>> On 26.04.2016 02:09, Grant Edwards wrote:
>>> Thanks again! Now I just have to decided whether to use
>>> intra-repository externals or nested working copies to share
>>> directories of source code among a group of projects. It may depend on
>>> how smartsvn handles tagging/branching that involves externals. I see
>>> that tortoisesvn has something akin to --pin-externals, but haven't
>>> figured out if smartsvn has something like that.
>> It does. The first version of SmartSVN that migrated off SVNKit to
>> JavaHL (from Subversion 1.8) had a two-step process for updating the
>> externals. The latest version should be using the atomic pin-externals
>> capability.
> Cool, thanks for the info. I'm going to set up a couple test projects
> and try out externals vs. nested working copies to make sure I
> understand the differences.
Externals /are/ nested working copies as far as the client is concerned.
Sure nothing prevents you from using nested working copies that aren't
tracked as externals, but you'll have to invent your own tooling for
checkouts, updates, commits, etc.
-- Brane
Re: Questions about --pin-externals option
Posted by Grant Edwards <gr...@gmail.com>.
On 2016-04-26, Branko Čibej <br...@apache.org> wrote:
> On 26.04.2016 02:09, Grant Edwards wrote:
>> Thanks again! Now I just have to decided whether to use
>> intra-repository externals or nested working copies to share
>> directories of source code among a group of projects. It may depend on
>> how smartsvn handles tagging/branching that involves externals. I see
>> that tortoisesvn has something akin to --pin-externals, but haven't
>> figured out if smartsvn has something like that.
>
> It does. The first version of SmartSVN that migrated off SVNKit to
> JavaHL (from Subversion 1.8) had a two-step process for updating the
> externals. The latest version should be using the atomic pin-externals
> capability.
Cool, thanks for the info. I'm going to set up a couple test projects
and try out externals vs. nested working copies to make sure I
understand the differences.
--
Grant Edwards grant.b.edwards Yow! My EARS are GONE!!
at
gmail.com
Re: Questions about --pin-externals option
Posted by Branko Čibej <br...@apache.org>.
On 26.04.2016 02:09, Grant Edwards wrote:
> Thanks again! Now I just have to decided whether to use
> intra-repository externals or nested working copies to share
> directories of source code among a group of projects. It may depend on
> how smartsvn handles tagging/branching that involves externals. I see
> that tortoisesvn has something akin to --pin-externals, but haven't
> figured out if smartsvn has something like that.
It does. The first version of SmartSVN that migrated off SVNKit to
JavaHL (from Subversion 1.8) had a two-step process for updating the
externals. The latest version should be using the atomic pin-externals
capability.
-- Brane
Re: Questions about --pin-externals option
Posted by Grant Edwards <gr...@gmail.com>.
On 2016-04-25, Stefan <lu...@posteo.de> wrote:
> Hi Edwards,
>> A couple questions regarding "svn copy --pin-externals":
>>
>> 1) I thought I saw that when the --pin-externals option was being
>> developed it handled things differently when the destination was a
>> tag verses a branch.
>>
>> IIRC, copy --pin-externals to a "tag" destination just pinned the
>> revision to the current one (leaving the path the same), but if the
>> destination was a "branch" and the source was relative, it would
>> leave the version floating and change the path so it too pointed to
>> a branch (or something like that).
>>
>> Did the branch handling stuff get dropped?
>
> That would be news to me. As far as I'm aware SVN does not treat
> tags/branches special in any case.
My bad. I spent some time repeating my Google searchs and it looks
like I was conflating the "svn copy --pin-externals" feature with some
features of the "svncopy" script (which I may have misunderstood just
to make the situation worse).
>> 2) Are there server-side version dependancies for use of the
>> --pin-externals option? Or will it work with any server version?
> This client-side feature works with any server but requires a client
> >= 1.9. Note that the feature to specify externals with peg revisions
> was actually added in 1.5 already [1]. That said, if you use that
> feature all clients which access the repository should be >= 1.5 to
> understand the syntax correctly. 1.9 only added that command line
> option to simplify working with externals.
Thanks, that's what I thought, but wanted to make sure.
>> Where does one find documentation for 1.9 versions (the book only
>> covers versions up to 1.8)?
> The SVN book for 1.8 is the most resent version available atm. Most of
> the information should still apply to SVN 1.9. A good source for the
> newly added features would be the release notes [2].
>
> [1]: https://subversion.apache.org/docs/release-notes/1.5.html
> [2]: https://subversion.apache.org/docs/release-notes/1.9.html
Thanks again!
Now I just have to decided whether to use intra-repository externals
or nested working copies to share directories of source code among a
group of projects. It may depend on how smartsvn handles
tagging/branching that involves externals. I see that tortoisesvn has
something akin to --pin-externals, but haven't figured out if smartsvn
has something like that.
--
Grant
Re: Questions about --pin-externals option
Posted by Stefan <lu...@posteo.de>.
Hi Edwards,
> A couple questions regarding "svn copy --pin-externals":
>
> 1) I thought I saw that when the --pin-externals option was being
> developed it handled things differently when the destination was a
> tag verses a branch.
>
> IIRC, copy --pin-externals to a "tag" destination just pinned the
> revision to the current one (leaving the path the same), but if the
> destination was a "branch" and the source was relative, it would
> leave the version floating and change the path so it too pointed to
> a branch (or something like that).
>
> Did the branch handling stuff get dropped?
That would be news to me. As far as I'm aware SVN does not treat
tags/branches special in any case.
To keep externals "floating" simply use externals without pinning them
to a certain revision, or am I getting your question wrong?
> 2) Are there server-side version dependancies for use of the
> --pin-externals option? Or will it work with any server version?
This client-side feature works with any server but requires a client >= 1.9.
Note that the feature to specify externals with peg revisions was
actually added in 1.5 already [1].
That said, if you use that feature all clients which access the
repository should be >= 1.5 to understand the syntax correctly.
1.9 only added that command line option to simplify working with externals.
> Where does one find documentation for 1.9 versions (the book only
> covers versions up to 1.8)?
The SVN book for 1.8 is the most resent version available atm. Most of
the information should still apply to SVN 1.9. A good source for the
newly added features would be the release notes [2].
[1]: https://subversion.apache.org/docs/release-notes/1.5.html
[2]: https://subversion.apache.org/docs/release-notes/1.9.html
Regards,
Stefan