Hi, Paul,
If at all, I’d expect a speed boost if the temp folder is on a fast drive (e.
G. SSD or RAM Disk) separate from the backend storage, so storage and temp file
I/O won’t compete for I/O. (Size of RAM useable for OS caches also makes a
difference, and mount options like “no-sync” which c
On Tue, Jul 11, 2017 at 09:11:58PM +0200, Branko Čibej wrote:
> Another issue I have with the proposal is the idea to use file suffixes.
> That's usually the wrong way to go about things (case in point: Windows
> does it, with didastrous results). It's much better to determine file
> format by insp
On 11.07.2017 10:53, Julian Foad wrote:
> Thanks for your suggestion, Nathan.
>
> Nathan Hartman wrote:
>> [...] What if, instead of just a pristine copy, it actually created a
>> private local repository. Revision 1 of this repository would be the
>> pristine copy. [...] if you type some other com
Sorry, pressed [Send] too early.
Thanks for the explanations. More below.
Daniel Shahaf wrote on Tue, 11 Jul 2017 22:02 +:
> Julian Foad wrote on Tue, 11 Jul 2017 21:53 +0100:
> > Daniel Shahaf wrote:
> > > Julian Foad wrote:
> > >> Checkpointing
> > >>
> > >> Options:
> > >>
> > >> 1. f
On Tue, Jul 11, 2017 at 4:53 AM, Julian Foad wrote:
> Nathan Hartman wrote:
>
>> [...] What if, instead of just a pristine copy, it actually created a
>> private local repository. Revision 1 of this repository would be the
>> pristine copy. [...]
>>
>
> That is exactly what I was thinking about w
Julian Foad wrote on Tue, 11 Jul 2017 21:53 +0100:
> Daniel Shahaf wrote:
> > Julian Foad wrote:
> >> Checkpointing
> >>
> >> Options:
> >>
> >> 1. further patch management built on a series of shelved changes
> >> 2. local commits tightly integrated
> >> 3. checkpoints are commits in a
Daniel Shahaf wrote:
Julian Foad wrote:
Checkpointing
Options:
1. further patch management built on a series of shelved changes
2. local commits tightly integrated
3. checkpoints are commits in a local repository
Can you explain these three options in more words? AIUI #1 is
"syn
On Tue, Jul 11, 2017 at 10:35:12PM +0200, Stefan Sperling wrote:
> On Tue, Jul 11, 2017 at 07:54:58PM +, Daniel Shahaf wrote:
> > As others have said, configure already supports both 2.x and 3.x. The
> > remaining question is just whether release.py should use 2.x or 3.x for
> > rolling tarbal
Stefan Sperling wrote:
On Tue, Jul 11, 2017 at 04:33:37PM +0100, Julian Foad wrote:
An improvement would be to show the pending status, perhaps like this:
...
A file scheduled to be added to the repository in the next commit was found in
the working copy.
Pending status of the file is:
RM
On Tue, Jul 11, 2017 at 07:54:58PM +, Daniel Shahaf wrote:
> As others have said, configure already supports both 2.x and 3.x. The
> remaining question is just whether release.py should use 2.x or 3.x for
> rolling tarballs. release.py uses own swig version compiled directly
> from swig upstr
On Mon, Jul 10, 2017 at 02:03:41PM +0100, Julian Foad wrote:
> Checkpointing
>
> Options:
>
>
>1.
>
>further patch management built on a series of shelved changes
>2.
>
>local commits tightly integrated
>3.
>
>checkpoints are commits in a local repository
Can you expl
Reporting back -
The /etc/apache2/envvars file is the *perfect* place to change the temp
folder that Apache uses on load, and avoid an out of space error for bg
files(see log above). I thought there might also be a speed boost for
having the temp folder set to the same driver as the destinati
So I'm after a time saving. I'm perfectly happy for the backend to waste
space (in my configuration), I just don't want it to take 15 mins to
transfer a single 15GB file into Subversion.
In my configuration, I'd like to pre-advise Subversion to save as much time
as possible for uploads, by skippin
On Tue, Jul 11, 2017 at 07:48:43AM +0200, Stefan Sperling wrote:
> On Mon, Jul 10, 2017 at 11:38:10PM +, Daniel Shahaf wrote:
> > Shall we bump the release.py swig version to 3.x for 1.10.x? Currently it
> > points to 2.0.12 which is over 3 years old and AFAICT deprecated upstream
> > (there w
On Tue, Jul 11, 2017 at 01:39:56PM +, Markus Schaber wrote:
> To summarize it up:
>
> I expect significant benefits in some use cases by skipping the
> compression, thus I'm +1 if benchmarks prove it's worth the effort.
It is easy to have deltification without compression, either by using
svn
I'm perfectly happy for the solution to be mime-type based.
Maybe we can take the mime-type to *suffix table* from Apache itself to do
the translation :- https://svn.apache.org/repos/asf/httpd/httpd/trunk/
docs/conf/mime.types :-P
I used it (implicitly) in a Subversion backed wysi-wiki *ten years
On Tue, Jul 11, 2017 at 04:33:37PM +0100, Julian Foad wrote:
> An improvement would be to show the pending status, perhaps like this:
>
> ...
> > A file scheduled to be added to the repository in the next commit was found
> > in the working copy.
> > Pending status of the file is:
> > RM sub
On 11.07.2017 15:39, Markus Schaber wrote:
> Hi, Paul,
>
>
> From: Paul Hammant [mailto:p...@hammant.org]
>
>> Markus - I've read your section on deltification and I can see evidence in
>> what you wrote that you're concurrently in favor of and against it (the
>> file-suffix exclusion idea). Can
I got an add-vs-add tree conflict during update, after applying a patch
which I had also separately committed to the repo from a different WC.
Here is how it looked:
$ svn up
Updating '.':
Gsubversion/svn/svn.c
C subversion/svn/shelve-cmd.c
Updated to revision 1801596.
Summary of confli
Hi, Paul,
From: Paul Hammant [mailto:p...@hammant.org]
> Markus - I've read your section on deltification and I can see evidence in
> what you wrote that you're concurrently in favor of and against it (the
> file-suffix exclusion idea). Can you re-read and clarify?
>> I agree partly. Skippin
Markus - I've read your section on deltification and I can see evidence in
what you wrote that you're concurrently in favor of and against it (the
file-suffix exclusion idea). Can you re-read and clarify?
Thanks,
- Paul
On Tue, Jul 11, 2017 at 8:53 AM, Markus Schaber
wrote:
> Hi,
>
> (Sorry, i
Hi,
Best regards
Markus Schaber
CODESYS® a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +4
Hi,
(Sorry, it seems my previous message was sent _very_ prematurely :-(
From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com]
> Hello Paul,
>
> On Sat, Jul 8, 2017 at 2:51 AM, Paul Hammant wrote:
> >
> > 1. compression-exempt-suffixes = mp3,mp4,jpeg
> >
> > 2. deltification-exempt-suffi
Hello Paul,
On Sat, Jul 8, 2017 at 2:51 AM, Paul Hammant wrote:
>
> 1. compression-exempt-suffixes = mp3,mp4,jpeg
>
> 2. deltification-exempt-suffixes = mp3,mp4,jpeg
>
> Regardless of the setting of 'compression-level', #1 above two mean certain
> things can skip the compression attempt. It mus
Philip Martin wrote:
Julian Foad writes:
Stefan Sperling wrote:
How far widespread is swig 3.0? It is not in OpenBSD ports yet, but perhaps
those lack behind?
The recent Debian stable release only has swig 3.
Now when I install swig 2 as well as 3, trunk 'configure' picks up
swig 2, and bu
Julian Foad writes:
> Stefan Sperling wrote:
>> How far widespread is swig 3.0? It is not in OpenBSD ports yet, but perhaps
>> those lack behind?
The recent Debian stable release only has swig 3.
> Now when I install swig 2 as well as 3, trunk 'configure' picks up
> swig 2, and build and test s
Thanks for your suggestion, Nathan.
Nathan Hartman wrote:
[...] What if, instead of just a pristine copy, it actually created a private local
repository. Revision 1 of this repository would be the pristine copy. [...] if you type
some other command instead of commit, or maybe prepend the word
Stefan Sperling wrote:
Daniel Shahaf wrote:
Shall we bump the release.py swig version to 3.x for 1.10.x? Currently it
points to 2.0.12 which is over 3 years old and AFAICT deprecated upstream
(there were no further releases of the 2.x line of swig).
How far widespread is swig 3.0? It is not i
28 matches
Mail list logo
