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
When I load a dump into an empty repo, will the operation be affected
by the hooks I have already set up for svnsync?
I have created dumpfiles for all 9 repos I want to sync, and now I am
about to load these into the repos I had prepared for sync when I
discovered that network problems interfered.
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, 28 Mar 2018 12:41:49 -0500, Bo Berglund
wrote:
>QUESTION:
>-
>Is there a possibility to dump the source repos, then use the
>dumpfiles to set up the mirrors and finally tell svnsync to start
>syncing from the revision that is now the last in the mirror?
It seems like 3 options ar
On Wed, 28 Mar 2018 09:00:05 +0200, Johan Corveleyn
wrote:
>> Transmitting file data ... 8 long lines of dots
>> ..svnsync: E120106: ra_serf: The server sent a
>> truncated HTTP response body.
>
>I'd start with going through the apache logs on both servers to look
>for mor
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
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 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
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 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 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 Wed, Mar 28, 2018 at 1:56 AM, Bo Berglund wrote:
> I proceeded to sync our repositories. On the 3rd repo I get the
> following error at revision 210 (it contains 1290 revisions):
>
> E:\>svnsync synchronize https://home.mirrordomain.com/svn/cmp
> https://masterserver/svn/cmp
> Transmitting file
12 matches
Mail list logo
