On 13.07.2017 04:07, Paul Hammant wrote:
> I flipped _back_ to Python's requests.put(..) in my solution - from a
> regular Svn client. That relies on 'autoversioning=on' for it to work
> over DAV, I mean. In that configuration it functions like curl, of
> course.
>
> _Commit Messages_
>
> I'd love
On 12.07.2017 21:50, Paul Hammant wrote:
> You know, in all seriousness I think the (empty by default) list of
> exempted files suffixes the the best way forward. If suffixes is good
> enough for Apache itself to use (link provided earlier), it is good
> enough in this scenario on the server side
I flipped *back* to Python's requests.put(..) in my solution - from a
regular Svn client. That relies on 'autoversioning=on' for it to work over
DAV, I mean. In that configuration it functions like curl, of course.
*Commit Messages*
I'd love a --header "svn:message: my message" too. I raised it
On Wed, Jul 12, 2017 at 10:40 PM, Paul Hammant wrote:
> I'd be fine with that too if it is also settable via curl --header
> "svn:compression: no" for non-client auto-increment operations.
I'm wondering whether you'll still need this. You ended up with
curl+autoversioning (at Philip's suggestion)
I'd be fine with that too if it is *also* settable via curl --header
"svn:compression: no" for non-client auto-increment operations.
On Wed, Jul 12, 2017 at 4:10 PM, Mark Phippard wrote:
> I cannot find it in archives so maybe this happened in IRC, but I remember
> one time suggesting we add a n
Bert Huijben wrote:
Julian Foad wrote:
Mark Phippard wrote:
[...] does patch just create conflicts that you
resolve like anything else?
It is 'svn patch' -- so it raises conflicts.
Svn patch creates reject files. It doesn't create conflicts (yet).
Gosh, so it does! How primitive! :-)
I
I cannot find it in archives so maybe this happened in IRC, but I remember
one time suggesting we add a new versioned svn:XXX property to control
this. This could then be set by the client based on extension if desired.
I recall my suggestion was a compression on|off property that when turned
off
You know, in all seriousness I think the (empty by default) list of
exempted files suffixes the the best way forward. If suffixes is good
enough for Apache itself to use (link provided earlier), it is good enough
in this scenario on the server side of Svn. If the function in question
doesn't know
> -Original Message-
> From: Julian Foad [mailto:julianf...@apache.org]
> Sent: woensdag 12 juli 2017 16:38
> To: Mark Phippard
> Cc: Subversion Developers
> Subject: Re: [RFC] Shelving and Checkpointing
>
> Mark Phippard wrote:
> > Nice to see you have gotten this far.
> >
> > I am no
Mark Phippard wrote:
Nice to see you have gotten this far.
I am not even sure how this behaves with git stash but what happens if
the patch cannot be applied cleanly? Is the path to "fixing things"
relatively clear? Like does patch just create conflicts that you
resolve like anything else?
Johan Corveleyn wrote:
I've quickly scanned your google docs, but have to go through them in
some more detail. I'll try to dig into them and give some feedback if
I can.
Thanks you Johan! I look forward to hearing your comments when you have
a chance.
One thing that crossed my mind: a nice
On Wed, Jul 12, 2017 at 4:18 AM, Julian Foad wrote:
> I committed an initial prototype for shelving on the "shelve-checkpoint"
> branch.
>
> Here is the help output:
> [[[
> $ svn shelve --help
> shelve: Shelve changes.
> usage: 1. shelve NAME PATH...
>2. shelve --delete NAME
>3.
On Mon, Jul 10, 2017 at 2:59 PM, Julian Foad wrote:
> Dear Subversion Developers,
>
> I am delighted to announce that I am working with Assembla to develop
> shelving and checkpointing functionality in Subversion. These have
> been on the wish list for many years, and are becoming ever more in
> d
Branko Čibej wrote on Wed, 12 Jul 2017 12:09 +0200:
> I wasn't really proposing to use libmagic on the server. My point is
> that instead of using file name suffixes (which the compression and
> deltification code don't know about), we'd do some sort of inspection
> instead. Detecting ZIP files, or
Hi,
From: Johan Corveleyn [mailto:jcor...@gmail.com]
> > That's such an easy way to make a malicious client explode the
> > repository size. And ... there's realy no reason to complicate. The
> > server's storage layer can cheaply do all the necessary checks without
> > having to believe the clien
On Wed, Jul 12, 2017 at 12:27 PM, Branko Čibej wrote:
> On 12.07.2017 12:24, Johan Corveleyn wrote:
>> On Wed, Jul 12, 2017 at 12:09 PM, Branko Čibej wrote:
>>> On 11.07.2017 22:50, Stefan Sperling wrote:
On Tue, Jul 11, 2017 at 09:11:58PM +0200, Branko Čibej wrote:
> Another issue I hav
On 12.07.2017 12:24, Johan Corveleyn wrote:
> On Wed, Jul 12, 2017 at 12:09 PM, Branko Čibej wrote:
>> On 11.07.2017 22:50, Stefan Sperling wrote:
>>> 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.
Th
On Wed, Jul 12, 2017 at 12:09 PM, Branko Čibej wrote:
> On 11.07.2017 22:50, Stefan Sperling wrote:
>> 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 (cas
On 12.07.2017 12:09, Branko Čibej wrote:
> On 11.07.2017 22:50, Stefan Sperling wrote:
>> 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: Wi
On 11.07.2017 22:50, Stefan Sperling wrote:
> 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
I committed an initial prototype for shelving on the "shelve-checkpoint"
branch.
Here is the help output:
[[[
$ svn shelve --help
shelve: Shelve changes.
usage: 1. shelve NAME PATH...
2. shelve --delete NAME
3. shelve --list
1. Shelve as NAME the local changes in the given PATHs
Daniel Shahaf wrote:
Julian Foad wrote on Tue, 11 Jul 2017 21:53 +0100:
2. What I was thinking there is to rewrite as much of our libs as needed
to implement deeply integrated local branching in Svn client. The full
extent of what that might entail or look like is unknown.
I don't understand t
22 matches
Mail list logo
