Stefan Kueng wrote:
>I'm still doing some testing with the new --pin-externals feature, and I
>found a situation which I'm not sure should be handled that way:
>
>imagine the repo is at r100. Now if one does a
>svn copy http://server/trunk http://server/branches/b1 -r50 --pin-externals
>
>then all
Translation status report for trunk@r1660269
lang trans untrans fuzzy obs
--
de2893 20 42 493 +~o
es2281 632 849 528 ++U~~~
fr2585 328
On 2/16/15 3:57 AM, Branko Čibej wrote:
> At first I thought I'd just lowercase the untranslated keys that 'svn
> info' displays, replacing spaces with dashes. But there's a strong case
> for using the same names as the --xml output; not because it's easier to
> implement, but because it's at least
On 2/15/15 6:29 PM, Branko Čibej wrote:
> * 4502 Remove FSFS7 disk format changes
> We've had this discussion several times. AIUI Ivan still believes we
> should remove log addressing, even though all of the points he
> raised have been addressed. I propose we close this issue.
I've
On 2/16/15 5:21 PM, Evgeny Kotkov wrote:
> 2) Install a non-abortive mod_dav_svn malfunction handler, which would log the
>malfunction details using ap_log_error() and return SVN_ERR_ASSERTION_FAIL
>when CAN_RETURN = TRUE. This option is similiar to the current behavior of
>a non-defau
Subversion's mod_dav_svn module currently uses a default malfunction handler,
svn_error_abort_on_malfunction(). This means that SVN_ERR_MALFUNCTION() or
failed SVN_ERR_ASSERT() statements output the malfunction details to STDERR
and abort() the current process. Doing so within an Apache module —
Stefan Kueng wrote:
> On 16.02.2015 20:39, Stefan Sperling wrote:
>> In general, externals point at different repositories. [...]
>> An intra-repository external (and especially
>> a configuration where all externals come from the same repository) is a
>> special
>> case where I don't think it is
On 16.02.2015 20:47, Stefan Kueng wrote:
>
>
> On 16.02.2015 20:39, Stefan Sperling wrote:
>> On Mon, Feb 16, 2015 at 08:01:19PM +0100, Stefan Kueng wrote:
>>> Hi,
>>>
>>> I'm still doing some testing with the new --pin-externals feature,
>>> and I
>>> found a situation which I'm not sure should be
On 16.02.2015 20:39, Stefan Sperling wrote:
On Mon, Feb 16, 2015 at 08:01:19PM +0100, Stefan Kueng wrote:
Hi,
I'm still doing some testing with the new --pin-externals feature, and I
found a situation which I'm not sure should be handled that way:
imagine the repo is at r100. Now if one does
On Mon, Feb 16, 2015 at 08:33:26PM +0100, Stefan Kueng wrote:
> My usual use case for creating a copy not from HEAD but an earlier revision
> is when I forgot to create a tag, and there have already been other commits
> done after making the release.
> So in that situation, it would be wrong to pin
On Mon, Feb 16, 2015 at 08:01:19PM +0100, Stefan Kueng wrote:
> Hi,
>
> I'm still doing some testing with the new --pin-externals feature, and I
> found a situation which I'm not sure should be handled that way:
>
> imagine the repo is at r100. Now if one does a
> svn copy http://server/trunk htt
On 16.02.2015 20:22, Bert Huijben wrote:
-Original Message- From: Stefan Kueng
[mailto:tortoise...@gmail.com] Sent: maandag 16 februari 2015
20:01 To: Subversion Development Subject: pin externals when
creating a copy from specific revision
Hi,
I'm still doing some testing with the
> -Original Message-
> From: Stefan Kueng [mailto:tortoise...@gmail.com]
> Sent: maandag 16 februari 2015 20:01
> To: Subversion Development
> Subject: pin externals when creating a copy from specific revision
>
> Hi,
>
> I'm still doing some testing with the new --pin-externals feature
Hi,
I'm still doing some testing with the new --pin-externals feature, and I
found a situation which I'm not sure should be handled that way:
imagine the repo is at r100. Now if one does a
svn copy http://server/trunk http://server/branches/b1 -r50 --pin-externals
then all externals get pinne
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 16 februari 2015 17:41
> To: dev@subversion.apache.org
> Cc: Bert Huijben; Stefan Sperling; Stefan Fuhrmann
> Subject: 1.8.x backport r1619380 - diff locally copied dir with props
>
> This issue
Op 16-feb.-2015 12:57 schreef "Branko Čibej" :
>
> On 16.02.2015 12:07, Julian Foad wrote:
> > Branko Čibej wrote:
> >>> * 4556 Replace 'svn youngest' with another UI
> >>> Not much discussion here. I propose we do either option 2
('svnmucc
> >>> youngest'), or rip out the subcommand en
Julian Foad writes:
> Do we want to:
>
> * backport first, then investigate and fix this case at leisure (on trunk)
> * hold off the backport until this is investigated and fixed?
Hold off. Avoid introducing a new bug into the stable code and keep the
existing bug.
--
Philip Martin | Subv
This issue is proposed for backport:
* r1619380, r1619393
Fix diff of a locally copied directory with props: it showed all props
as added instead of a diff against the copy-from props.
Justification:
Behaviour regression introduced in 1.8.0.
Notes:
r1619380 is the fix; r161
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
> * 4558, 4559, 4560: These are all about pin-externals. They shouldn't
> take too long to fix; basically, the
On 16.02.2015 13:05, Sergey Raevskiy wrote:
> Please ignore this e-mail (I accidentally sent it to the wrong mailing list).
Yes, I was wondering what kind of assignment you got for Subversion, and
where it came from. :)
-- Brane
Please ignore this e-mail (I accidentally sent it to the wrong mailing list).
On 16.02.2015 12:07, Julian Foad wrote:
> Branko Čibej wrote:
>>> * 4556 Replace 'svn youngest' with another UI
>>> Not much discussion here. I propose we do either option 2 ('svnmucc
>>> youngest'), or rip out the subcommand entirely since there are lots
>>> of ways to the info.
>
Коллеги,
для задачи K531 на нужно утвердить следующие тексты:
1) Текст для ситуации, когда post-lock hook выдал ошибку на master
(при выполнении svn lock через slave)
Keyword: MSG_VDFS_POST_LOCK_HOOK_ERROR
Сейчас:
[[[
An error occurred with post-processing of lock operation.
Repository: master
P
Branko Čibej wrote:
>> * 4556 Replace 'svn youngest' with another UI
>> Not much discussion here. I propose we do either option 2 ('svnmucc
>> youngest'), or rip out the subcommand entirely since there are lots
>> of ways to the info.
>
> I'm going to have a go at an alternative solu
On 16.02.2015 10:27, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: maandag 16 februari 2015 03:14
>> To: 'Subversion Development'
>> Subject: Re: Time to branch 1.9
>>
>> On 15.02.2015 14:24, Branko Čibej wrote:
>>> On 15.02.2015 01:0
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:14
> To: 'Subversion Development'
> Subject: Re: Time to branch 1.9
>
> On 15.02.2015 14:24, Branko Čibej wrote:
> > On 15.02.2015 01:03, Bert Huijben wrote:
> >>> -Original Mess
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
>
> On 12.02.2015 11:12, Branko Čibej wrote:
> > On 16.01.2015 11:06, Branko Čibej wrote:
> >> A couple months down
27 matches
Mail list logo
