On Thu, Feb 28, 2013 at 10:01 PM, Kevin Jennings
<kkjennings_at_sbcglobal.net> wrote:
>>
>> The only way you could do it would be to create a private tag of the
>> external in its own repository with the sub-external pegged. In order
>> to do that you need write access to the external's repo.
>>
>
> I don't know if write access to the external's repo is required to create
> a private tag, but I'll take your word on it since you know it better than
> me. It seems like I'm "just" asking for a way to create a permanent
> snapshot of the state of a repository branch. I realize that Tortoise is
> also constrained by the underlying capabilities of Subversion, but if
> there is no good way to work around the problem then that's just the way
> that it is.
Perhaps this is best shown by example.
Consider three repositories:
http://example.com/repoA
http://example.com/repoB
http://example.com/PrivateRepoWithReadOnlyAccess
repoA has:
trunk
myFancyProj
external: http://example.com/PrivateRepoWithReadOnlyAccess/trunk/myFancyLib
PrivateLib
PrivateRepoWithReadOnlyAccess has:
myFancyLib
external: http://example.com/repoB/trunk OtherLib
Now, say you make a tag in repoA, and you want to lock down externals. So,
the external in repoA needs to become something like:
http://example.com/PrivateRepoWithReadOnlyAccess/trunk/myFancyLib@1234
PrivateLib
This is easily accomplished. But how do you "lock down" the revision of
repoB pulled into PrivateRepoWithReadOnlyAccess?
You need SVN to change the external in PrivateRepoWithReadOnlyAccess to
something like:
http://example.com/repoB/trunk@456 OtherLib
But, you don't have write access to PrivateRepoWithReadOnlyAccess! This is
especially problematic if you pull in any third-party libraries, etc. as
externals.
How could you work around this? Well, if you don't actually depend on repoB,
maybe you don't need to. If you actually compile against or include repoB in
your project in some way, you could pull it in directly instead, with a new
project with a "flat" externals structure, where you control all externals
which will actually be used by your build/deployment setup.
In our example, such a repository could look like:
http://example.com/BuildRepo
trunk
makefile (referencing only Proj, PrivateLib, and OtherLib, avoiding
nested directories)
external: http://example.com/repoA/myFancyProj Proj
external: http://example.com/PrivateRepoWithReadOnlyAccess PrivateLib
external: http://example.com/repoB http://example.com/repoB/trunk OtherLib
Here's another solution:
Someone mentioned creating private tags. If you have write access to each
repository, you could easily do this manually. In this case, start by
creating a tag for repoB. Then tag PrivateRepoWithReadOnlyAccess, and update
the tag to point to the specific revision of repoB. Finally, tag repoA, and
update the tag to point to the tagged version of
PrivateRepoWithReadOnlyAccess.
This relies on the assumption that your externals point to self-contained
units which could be tagged separately from each other. If this is not the
case, it will be harder to accomplish. But this manual method is basically
what you're asking TSVN to do.
I'm curious what the recursive tagging (mentioned in another post as coming
to version 1.8) will do.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3050123
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-03-01 17:42:52 CET