On Thu, Sep 21, 2017 at 12:16 PM, Paul Hammant wrote:
>>
>>
>> 2. Previously I forked a medium-sized Monorepo on Github, and did the the
>> complete expand/contract work for it -
>> https://github.com/paul-hammant-fork/jooby-monorepo-experiment - in Python.
>>
>
> LOGIBALL's Tim Krüger has just wr
>
>
> I'm not sure if you agree or not, but I think the fine-grained globbing
> include/exclude capability as Perforce has it. is required.
>
>
> "Required" implies "working copy format change". That's always hard.
>
> "Optional" means "get some of the features sooner."
>
I'm a big advocate for "s
On 21.09.2017 12:08, Paul Hammant wrote:
>
> [...]
>
> if /foo does not exist at checkout time -- and if we'd want /* to mean
> "include anything new that appears in the repository", not "include
> everything else that's in the repository at the time of the checkout".
>
>
> I'm not
>
>
>
> 2. Previously I forked a medium-sized Monorepo on Github, and did the the
> complete expand/contract work for it - https://github.com/paul-hamm
> ant-fork/jooby-monorepo-experiment - in Python.
>
>
LOGIBALL's Tim Krüger has just written about a deployment of an
expanding/contracting monorep
>
> [...]
>
> if /foo does not exist at checkout time -- and if we'd want /* to mean
> "include anything new that appears in the repository", not "include
> everything else that's in the repository at the time of the checkout".
>
I'm not sure if you agree or not, but I think the fine-grained globb
On 20.09.2017 08:48, Branko Čibej wrote:
> On 19.09.2017 18:05, Branko Čibej wrote:
>> On 19.09.2017 13:24, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
On 19.09.2017 00:59, Paul Hammant wrote:
> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if
On 19.09.2017 18:05, Branko Čibej wrote:
> On 19.09.2017 13:24, Daniel Shahaf wrote:
>> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
>>> On 19.09.2017 00:59, Paul Hammant wrote:
I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
following `svn up` it would *remember
On 19.09.2017 13:24, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
>> On 19.09.2017 00:59, Paul Hammant wrote:
>>> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
>>> following `svn up` it would *remember the current view*, it would be good.
>>
>> I d
Branko Čibej wrote on Tue, 19 Sep 2017 06:03 +0200:
> On 19.09.2017 00:59, Paul Hammant wrote:
> > I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> > following `svn up` it would *remember the current view*, it would be good.
>
>
> I don't think there's any need to remember the
> On 19.09.2017 00:59, Paul Hammant wrote:
> > I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> > following `svn up` it would *remember the current view*, it would be
> good.
>
>
> I don't think there's any need to remember the "current view": a sparse
> working copy already mai
On 19.09.2017 00:59, Paul Hammant wrote:
> I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
> following `svn up` it would *remember the current view*, it would be good.
I don't think there's any need to remember the "current view": a sparse
working copy already maintains its top
I like the `svn co svn://vcs/trunk --view foo`. Well maybe if in a
following `svn up` it would *remember the current view*, it would be good.
> I'm not sure about listing the "available views" in a default
> property, but okay, it's a possibility. I think it would be nice to be
> able to read it
On Wed, Sep 13, 2017 at 12:45 PM, Paul Hammant wrote:
>>
>>
>> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
>>
>
> Excellent!
>
> I see you posted a StackOverflow answer on that too, Mark -
> https://stackoverflow.com/questions/7481860/create-folder-structure-
On 16.09.2017 20:06, Paul Hammant wrote:
>
>
> foo.py:
>
> import os
> def my_mocked_os_system(*args, **kwargs):
> print('a mockery')
> os.system = my_mocked_os_system
>
>
> bar.py:
>
> import os
> os.system("echo bar")
>
> import foo
> os.system("echo fo
>
>
> foo.py:
>
> import os
> def my_mocked_os_system(*args, **kwargs):
> print('a mockery')
> os.system = my_mocked_os_system
>
>
> bar.py:
>
> import os
> os.system("echo bar")
>
> import foo
> os.system("echo foo")
>
>
> Then:
>
> $ PYTHONPATH=. python bar.py
> bar
> a mockery
>
>
I've spent
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 itse
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 '
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 s
>
> 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
> subversion/tests/cmdline/svntest/mai
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 burden
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.
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
>
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
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
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 a
On 13.09.2017 19:47, Paul Hammant wrote:
> OK, so I am up at 93% coverage with a PyTest script. As an Apache
> Member I'm already CLA'd. I could start to write tests that break the
> script in ways that it should handle more gracefully, but I need
> assurance that I'm not wasting my time.
>
> I'm n
On 13.09.2017 12:40, Paul Hammant wrote:
>
> > This is an old idea. If you want to implement it, a file is
> not the
> > right place for the view definition; a property on a directory
> > might be.
> >
> >
> > A Svn property that sets for the user and workspa
OK, so I am up at 93% coverage with a PyTest script. As an Apache Member
I'm already CLA'd. I could start to write tests that break the script in
ways that it should handle more gracefully, but I need assurance that I'm
not wasting my time.
I'm not expecting committership (especially since my last
T'was line endings and redundant spaces, fixed with a strip(), but as I
say, Java's asserts are better to noobs.
Here's the test:
https://gist.github.com/paul-hammant/058161485a227299e5d7c34cc6a33264
I had to refactor the actual script too. A tiny backwards-compatible bit.
-ph
I have a test for the inlined example. Well it would pass, but PyTest's
assert function is about 10x inferior to JUnit's or Hamcrest's
assertEquals() and isn't telling me where I've futzed up a CR somewhere.
This even *with* optional args (that should be mandatory -s and -vv). Gotta
go to work now
On Wed, Sep 13, 2017 at 06:53:14AM -0400, Paul Hammant wrote:
> Oh tools/client-side/svn-viewspec.py doesn't have any tests :-(
>
> The good news is that it can be refactored to have test quite easily. I
> think I'll be able to donate some code.
I would also be happy to see further improvements t
Oh tools/client-side/svn-viewspec.py doesn't have any tests :-(
The good news is that it can be refactored to have test quite easily. I
think I'll be able to donate some code.
>
>
> http://svn.apache.org/repos/asf/subversion/trunk/tools/
> client-side/svn-viewspec.py
>
>
Excellent!
I see you posted a StackOverflow answer on that too, Mark -
https://stackoverflow.com/questions/7481860/create-folder-structure-based-on-file
I'm one of those people that's blind to a lib or
> > This is an old idea. If you want to implement it, a file is not the
> > right place for the view definition; a property on a directory
> > might be.
> >
> >
> > A Svn property that sets for the user and workspace only, and retains
> > no history, right? Meaning if the user had two
Have you seen:
http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
> On Sep 12, 2017, at 10:22 PM, Paul Hammant wrote:
>
> Compared to Perforce's client-spec, Subversion's sparse checkouts are quite
> cumbersome:
>
> svn checkout http://svn.apache.org/repos/as
On 13.09.2017 09:25, Paul Hammant wrote:
>
> This is an old idea. If you want to implement it, a file is not the
> right place for the view definition; a property on a directory
> might be.
>
>
> A Svn property that sets for the user and workspace only, and retains
> no history, right?
>
> This is an old idea. If you want to implement it, a file is not the
> right place for the view definition; a property on a directory might be.
>
A Svn property that sets for the user and workspace only, and retains no
history, right? Meaning if the user had two checkouts of the same Svn URL,
On 13.09.2017 04:22, Paul Hammant wrote:
> Compared to Perforce's client-spec, Subversion's sparse checkouts are
> quite cumbersome:
>
> svn checkout http://svn.apache.org/repos/asf/subversion
> --depth=immediates
> cd subversion/trunk
> svn update --set-depth infinity
> cd ../t
Compared to Perforce's client-spec, Subversion's sparse checkouts are quite
cumbersome:
svn checkout http://svn.apache.org/repos/asf/subversion --depth=immediates
cd subversion/trunk
svn update --set-depth infinity
cd ../tags
svn update --set-depth immediates
cd 1.7.7
svn update --set-depth infini
39 matches
Mail list logo
