On 10.12.2012 07:35, Bert Huijben wrote:
> I don’t think you have to wait until commit time: You could verify the
> commit base revision’s properties + changes. In the cases where the
> properties change before commit, the commit would fail for being out of
> date.
That would imply you can't chang
I don’t think you have to wait until commit time: You could verify the
commit base revision’s properties + changes. In the cases where the
properties change before commit, the commit would fail for being out of
date.
Bert
*From:* Branko Čibej
*Sent:* December 10, 2012 12:26 AM
*To:* de
On 10.12.2012 01:25, Johan Corveleyn wrote:
> Another known offender is git-svn, because they don't care about
> translating line termination. So if you use git-svn on Windows, you
> might end up committing an eol-style=native file with CRLF's in to the
> repository.
Yuck. We should shout *really*
On 10.12.2012 01:24, Stefan Fuhrmann wrote:
> Well, if we really want to implement such a feature,
> we may as well be a bit more clever about it: While
> writing incoming file contents to the protrev file, we
> may determine its NL style as we go and store the
> result. The latter could then be co
1.7.0@1181106 vs. trunk@1418963
Started at Mon Dec 10 00:25:24 UTC 2012
*DISCLAIMER* - This tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Charts of t
On Mon, Dec 10, 2012 at 12:26 AM, Branko Čibej wrote:
> On 10.12.2012 00:08, Johan Corveleyn wrote:
>> On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf
>> wrote:
>>> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
2) Am I the only one who wants to protect his repository against
On Mon, Dec 10, 2012 at 12:26 AM, Branko Čibej wrote:
> On 10.12.2012 00:08, Johan Corveleyn wrote:
> > On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf
> wrote:
> >> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
> >>> 2) Am I the only one who wants to protect his repository agains
On 10.12.2012 00:21, Daniel Shahaf wrote:
>> As for my 1st concern, about the slowness of the pre-commit hook
>> validation, it might be possible to make it faster if both 'svnlook
>> pg' and 'svnlook cat' would support multiple targets.
> Or if you wrote your hook script using the Python bindings.
On 10.12.2012 00:08, Johan Corveleyn wrote:
> On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf
> wrote:
>> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
>>> 2) Am I the only one who wants to protect his repository against this
>>> corruption? Judging from [1], I don't think so. It d
Johan Corveleyn wrote on Mon, Dec 10, 2012 at 00:08:26 +0100:
> On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf
> wrote:
> > Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
> >> 2) Am I the only one who wants to protect his repository against this
> >> corruption? Judging from [1], I
On Sun, Dec 9, 2012 at 11:43 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
>> 2) Am I the only one who wants to protect his repository against this
>> corruption? Judging from [1], I don't think so. It doesn't make sense
>> that everyone starts writing th
Johan Corveleyn wrote on Sun, Dec 09, 2012 at 21:15:24 +0100:
> 2) Am I the only one who wants to protect his repository against this
> corruption? Judging from [1], I don't think so. It doesn't make sense
> that everyone starts writing this pre-commit hook, for something that
> IMHO is an obvious
On Sun, Dec 9, 2012 at 11:42 AM, Branko Čibej wrote:
> On 09.12.2012 09:14, Daniel Shahaf wrote:
>> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 01:02:55 +0100:
>>> Last week a colleague managed to commit a non-LF-normalized
>>> svn:eol-style=native file in our repository again. As explained in
>
On Sun, Dec 9, 2012 at 3:50 PM, Branko Čibej wrote:
> On 09.12.2012 15:05, stef...@apache.org wrote:
> > Representation sharing interacts badly with our skip-delta algorithm
> > as the former potentially extends the delta chain without making that
> > immediately visible in the noderev tree used
Hi there,
Ben asked me on IRC what the worst case scenario for rep
deltification in FSFS and I gave him the obvious answer.
Thinking about it just a little more would have lead me straight
to a design flaw / side effect that came with rep sharing:
When a noderev history e.g. starts with a shared
On 09.12.2012 15:05, stef...@apache.org wrote:
> Representation sharing interacts badly with our skip-delta algorithm
> as the former potentially extends the delta chain without making that
> immediately visible in the noderev tree used by choose_delta_base.
I don't understand this. How can repres
On 09.12.2012 09:14, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sun, Dec 09, 2012 at 01:02:55 +0100:
>> Last week a colleague managed to commit a non-LF-normalized
>> svn:eol-style=native file in our repository again. As explained in
>> issue #4065 [1], this causes all kinds of problems.
>>
>>
On Sat, Dec 8, 2012 at 5:46 PM, Shivani Poddar
wrote:
> Based on the reviews for the earlier PATCH for the svn_checksum.h header's
> python binding i have incorporated the required changes and finally have
> shaped the earlier patch.
> Please find the new patch file attached.
>
>
> log message:
>
Johan Corveleyn wrote on Sun, Dec 09, 2012 at 01:02:55 +0100:
> Last week a colleague managed to commit a non-LF-normalized
> svn:eol-style=native file in our repository again. As explained in
> issue #4065 [1], this causes all kinds of problems.
>
> I suspect there might be a bug in SVNKit, some
19 matches
Mail list logo
