Re: Idea: water...@subversion.apache.org mailing list

On Mon, Aug 21, 2017 at 03:28:35PM +0200, Johan Corveleyn wrote: > Maybe one of the downstreamers that happens to read this could chime > in with their thoughts? Right now we're mostly hypothesizing from our > end ... As a downstream package owner (Fedora/RHEL) I'd be happy to subscribe to a low

Re: Tip of the day: Cheatsheet for common cmdline client operations

Hello, On Wed, Aug 30, 2017 at 11:22 PM, Johan Corveleyn wrote: > > On Tue, Aug 29, 2017 at 2:15 PM, Pavel Lyalyakin > wrote: > > Hello, > > > > On Fri, Aug 25, 2017 at 2:03 PM, Johan Corveleyn wrote: > >> > >> [ cc -=

Re: Supporting multiple WC formats

On 14.09.2017 17:03, Branko Čibej wrote: > On 14.09.2017 14:47, Branko Čibej wrote: >> On 14.09.2017 11:48, Johan Corveleyn wrote: >>> My opinion: don't allow upgrading individual externals-sub-wc's. It's >>> all or nothing IMHO. >> That's the way I'm leaning, too. I do have to figure out if the

Re: Supporting multiple WC formats

On 14.09.2017 14:47, Branko Čibej wrote: > On 14.09.2017 11:48, Johan Corveleyn wrote: >> My opinion: don't allow upgrading individual externals-sub-wc's. It's >> all or nothing IMHO. > That's the way I'm leaning, too. I do have to figure out if the code for > that is already in place, or whether

Re: Sparse checkouts suggestion

On 14.09.2017 15:49, Paul Hammant wrote: > Would I retain the previous value of os.system and set it back after > any assertions (pass or fail) so that following tests would not affected? > Or does it und itself naturally when Pytest recurses in the next test > in its suite ? It wouldn't undo

Re: Sparse checkouts suggestion

Would I retain the previous value of os.system and set it back after any assertions (pass or fail) so that following tests would not affected? Or does it und itself naturally when Pytest recurses in the next test in its suite ? As I hinted I couldn't find such an example online, with an emphatic

Re: Sparse checkouts suggestion

On 14.09.2017 15:29, Paul Hammant wrote: > > Yes, that one's pretty nice, but as a rule we try not to burden our > users with dependencies outside the standard library. The script uses > os.system, what, twice? Hardly worth replacing. > > On the other hand, we have wrappers around

Re: Sparse checkouts suggestion

> > Yes, that one's pretty nice, but as a rule we try not to burden our > users with dependencies outside the standard library. The script uses > os.system, what, twice? Hardly worth replacing. > > On the other hand, we have wrappers around subprocess.Popen in >

Re: Building Subversion.

> > > > If yes, do you have the homebrew installables you needed handy? > > #LemmeKnowPls > > "brew install subversion"? > > I've done't that already, but I'm switching hats from 'user' to 'developer' of subversion. The brew installables I was thinking of were the development pre-requisites for

Re: Building Subversion.

On 14.09.2017 15:05, Branko Čibej wrote: > On 14.09.2017 13:36, Paul Hammant wrote: >> The tests made for https://github.com/apache/subversion/pull/5 didn't >> even require me to have Svn on my system. That's because I'm asserting >> against a series of expected shell operations, because that's

Re: Building Subversion.

On Thu, Sep 14, 2017 at 08:29:25AM -0400, Paul Hammant wrote: > The needs of the book are different to the needs of the Svn project. And > the needs of the project are far more important than one of a few Svn books. I don't understand this reasoning. The book doesn't receive the attention it

Re: Sparse checkouts suggestion

On 14.09.2017 15:04, Paul Hammant wrote: > My aim was to minimally impact the prod source. The context object is > a good idea. > > I've been using https://amoffat.github.io/sh/ and quite enjoying it > for my other python/svn project. Yes, that one's pretty nice, but as a rule we try not to

Re: Building Subversion.

On 14.09.2017 13:36, Paul Hammant wrote: > The tests made for https://github.com/apache/subversion/pull/5 didn't > even require me to have Svn on my system. That's because I'm asserting > against a series of expected shell operations, because that's how the > author implemented svn-viewspec > >

Re: Sparse checkouts suggestion

My aim was to minimally impact the prod source. The context object is a good idea. I've been using https://amoffat.github.io/sh/ and quite enjoying it for my other python/svn project.

Re: Building Subversion.

On Thu, Sep 14, 2017 at 08:24:35AM -0400, Nathan Hartman wrote: > It's on my > long to-do list to send in some patches and I'm hoping others will > jump in too, particularly to write a chapter on some advanced real > world usage scenarios, like workflow strategies to scale up a > development team

Re: Sparse checkouts suggestion

On 14.09.2017 14:50, Paul Hammant wrote: > I ran pep8 over the sources and thought I'd remediated all the > training spaces already. I'll finish the job. > > My alternative to the four globals is to pass the function pointers as > parameters through one or two intermediates to the functions that >

Re: Supporting multiple WC formats

On 14.09.2017 14:46, C. Michael Pilato wrote: > On 09/14/2017 12:01 AM, Branko Čibej wrote: >> As you may have noticed, I started implementing support for multiple WC >> formats on the better-pristines branch, as a prelude to adding support >> for compressed pristines without forcing users to

Re: Sparse checkouts suggestion

I ran pep8 over the sources and thought I'd remediated all the training spaces already. I'll finish the job. My alternative to the four globals is to pass the function pointers as parameters through one or two intermediates to the functions that would use them. Would that be acceptable? I can't

Re: Supporting multiple WC formats

On 09/14/2017 12:01 AM, Branko Čibej wrote: > As you may have noticed, I started implementing support for multiple WC > formats on the better-pristines branch, as a prelude to adding support > for compressed pristines without forcing users to upgrade all their > working copies. Sweet! > The

Re: Sparse checkouts suggestion

On 14.09.2017 12:26, Paul Hammant wrote: > Thanks.  > > Here's what I expect to land - https://github.com/apache/subversion/pull/5 Why o why did you go to the trouble of adding the global variables in svn-viewspec.py? They add exactly zero value and cause nothing but code churn. -1 to that change

Re: Building Subversion.

The needs of the book are different to the needs of the Svn project. And the needs of the project are far more important than one of a few Svn books. I'm going to stand by what I said. -ph

Re: Building Subversion.

On Sep 14, 2017, at 7:36 AM, Paul Hammant wrote: > Generally, the Subversion project should depend less on the Redbean book. > http://svnbook.red-bean.com/en/1.8/index.html is about 1.8 and it's marked as > DRAFT. There's no 1.9 or 1.10. While it is great that Msssrs. >

Building Subversion.

The tests made for https://github.com/apache/subversion/pull/5 didn't even require me to have Svn on my system. That's because I'm asserting against a series of expected shell operations, because that's how the author implemented svn-viewspec Has anyone built Subversion on a Mac? If yes, do you

Re: Sparse checkouts suggestion

Thanks. Here's what I expect to land - https://github.com/apache/subversion/pull/5 Ten tests - ten passing in less than 0.1s I don't know if there is a clean workflow from Git commits back into Subversion so, I'll make the same commit through the Svn HTTPS interface, if code review comments are

[GitHub] subversion pull request #5: pytest tests for svn-viewspec

GitHub user paul-hammant opened a pull request: https://github.com/apache/subversion/pull/5 pytest tests for svn-viewspec You can merge this pull request into a Git repository by running: $ git pull https://github.com/paul-hammant/subversion trunk Alternatively you can

Re: Supporting multiple WC formats

On Thu, Sep 14, 2017 at 6:01 AM, Branko Čibej wrote: > As you may have noticed, I started implementing support for multiple WC > formats on the better-pristines branch, as a prelude to adding support > for compressed pristines without forcing users to upgrade all their > working