I have a tree where one folder is referencing some other folders and documents
in different parts of the tree. And those externals are pegged.
So, I did a rename of the top folder of the tree. Which of course breaks the
externals.
So, I go fix the externals to be like they should, using the o
On Mar 26, 2018, at 17:20, Jonathan Schell wrote:
> I have a tree where one folder is referencing some other folders and
> documents in different parts of the tree. And those externals are pegged.
>
> So, I did a rename of the top folder of the tree. Which of course breaks the
> externals.
>
On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt
wrote:
>
> On Mar 26, 2018, at 17:20, Jonathan Schell wrote:
>
>> I have a tree where one folder is referencing some other folders and
>> documents in different parts of the tree. And those externals are pegged.
>>
>> So, I did a rename of the top f
ay, March 27, 2018 1:49 AM
To: Jonathan Schell
Cc: Subversion Users ; Ryan Schmidt
Subject: Re: issue with relative externals after a rename
On Tue, Mar 27, 2018 at 10:46 AM, Ryan Schmidt
wrote:
>
> On Mar 26, 2018, at 17:20, Jonathan Schell wrote:
>
>> I have a tree where
On 28.03.2018 01:38, Jonathan Schell wrote:
> I have a tree that looks like:
>
> https://svn/repo/name1/externs/normal_files_here
>
> The folder "externs" has two external properties:
> ../fold1@18 fold1
> ../fold2/file1.txt@18 file1.txt
>
> These folders and file exist at rev 18. The commit to ad
On Wed, Mar 28, 2018 at 5:36 AM, Branko Čibej wrote:
> On 28.03.2018 01:38, Jonathan Schell wrote:
>> I have a tree that looks like:
>>
>> https://svn/repo/name1/externs/normal_files_here
>>
>> The folder "externs" has two external properties:
>> ../fold1@18 fold1
>> ../fold2/file1.txt@18 file1.tx
On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej wrote:
> Because the default operative revision is HEAD and there's no such
> object in HEAD, yes.
[snip]
> You need both peg and operative revisions:
>
> -r 18 ../fold1 fold1@18
> -r 18 ../fold2/file1.txt@18 file1.txt
>
> The peg revision tells
On Wed, Mar 28, 2018 at 10:36 AM, Nathan Hartman
wrote:
> Our requirements are: at any time in the future, if someone checks
> out code from the past, they should get exactly the same tree as what
> existed in the past. I assume that this is probably THE #1 use case
> and desired behavior for ext
On Wed, Mar 28, 2018 at 10:59 AM, Nico Kadel-Garcia
wrote:
> On Wed, Mar 28, 2018 at 10:36 AM, Nathan Hartman
> wrote:
>
> > Our requirements are: at any time in the future, if someone checks
> > out code from the past, they should get exactly the same tree as what
> > existed in the past. I ass
Just curious since I am working on setting up our svn repositories migrated
from CVS.How does one "lock down" tags to disallow further commits? In CVS that
was built-in but svn works differently...
Bo B.
On 3/28/2018 9:37 AM, Bo Berglund wrote:
Just curious since I am working on setting up our svn repositories
migrated from CVS.
How does one "lock down" tags to disallow further commits? In CVS that
was built-in but svn works differently...
Bo B.
Put a check for the commit path(s) in the p
On Wed, Mar 28, 2018 at 4:36 PM, Nathan Hartman
wrote:
> On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej wrote:
>>
>> Because the default operative revision is HEAD and there's no such
>> object in HEAD, yes.
>
>
> [snip]
>
>>
>> You need both peg and operative revisions:
>>
>> -r 18 ../fold1 fold
On Wed, Mar 28, 2018 at 7:48 PM Johan Corveleyn wrote:
>
> No, you do not need to change your externals. I believe your
> understanding is correct, and I think Branko was incorrect. Indeed, in
> the absence of an operative revision, the operative revision defaults
> to the peg revision (so it do
13 matches
Mail list logo
