Re: [Twisted-Python] Adding mock as a test suite dependency

[Itamar Turner-Trauring]

On Sun, Oct 21, 2012 at 11:00 PM, Glyph  wrote:

>
> This seems like a pretty small benefit; adding a new dependency affects
> lots of people and introduces a new point of failure in the installation
> process, especially for Windows users who already have a devil of a time
> getting Twisted installed.
>

A testing dependency isn't quite as problematic as a regular dependency;
you'd only need to install it if you wanted to run Twisted's test suite,
which probably most users do not bother with.

-- 
Itamar Turner-Trauring, Future Foundries LLC
http://futurefoundries.com/ — Twisted consulting, training and support.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Jasper St. Pierre]

On Sun, Oct 21, 2012 at 11:00 PM, Glyph  wrote:
> On Oct 21, 2012, at 7:45 PM, Julian Berman  wrote:
>
> This seems like a pretty small benefit; adding a new dependency affects lots
> of people and introduces a new point of failure in the installation process,
> especially for Windows users who already have a devil of a time getting
> Twisted installed.

Is there anything we can do to make the dependency stuff nicer to
install on Windows, other than throwing out all niceties that we can
depend on? It seems that the issue here is our lack of good
installation story on Windows.

> Also I don't particularly like the testing style associated with Mock.  I
> think it might discourage us yet further from writing verified fakes, i.e.
> supported in-memory implementations of things like IReactorTCP, that have
> somewhat intricate behavior that's tedious to emulate with Mock.
>
> Personally I'm -0.  Don't let that stop you from cooking up a patch that
> would include it though, I might be in the minority here.
>
> -glyph
>
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>



-- 
  Jasper

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Managing twisted application as init service.

[Maxim Lacrima]

Hi,

I have been developing an application, which I would like to manage in a
fashion similar to scripts placed in /etc/init.d. I.e. I want to start,
stop, restart and monitor the application.

Currently, I am trying to figure out a correct approach for this. Initially
I thought to create a wrapper shell script like here [1] and just copy it
into `/etc/init.d` directory. Then in that script I would make `twistd`
start the application.

However, today I discovered `twisted.runner` package,  which seems to do
the same thing.  So my question is how to run and monitor processes
using `twisted.runner`? I couldn't find any examples on how to use it.

Also, in 11th part of the tutorial [2] there is a mention that I can
package my application as rpm package, which, when installed, will
correctly register my package as `init.d` script.

So are there best practices in twisted about how to install twisted
applications and manage them as `init.d` services?

I am quite new to Twisted (and to Linux `init.d` scripts). Sorry, if my
question is unclear.

Thank you in advance.

[1] http://www.sensi.org/~alec/unix/redhat/sysvinit.html
[2]
http://twistedmatrix.com/documents/current/core/howto/tutorial/configuration.html#auto4

-- 
with regards,
Maxim
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[exarkun]

On 03:00 am, gl...@twistedmatrix.com wrote:
>On Oct 21, 2012, at 7:45 PM, Julian Berman  
>wrote:
>>The *benefit* though for me in having mock present is that it 
>>decreases the
>>lines of code necessary to write stubs and mocks. While doing so is 
>>not really
>>that difficult anyhow, it *is* just a bit more clutter to do so 
>>without mock,
>>and the extra 3 or 4 lines mean that in more than one instance I have 
>>found
>>myself pick a different strategy than I would have because of the 
>>extra lines
>>of code that clutter the test method.
>
>This seems like a pretty small benefit; adding a new dependency affects 
>lots of people and introduces a new point of failure in the 
>installation process, especially for Windows users who already have a 
>devil of a time getting Twisted installed.
>
>Also I don't particularly like the testing style associated with Mock. 
>I think it might discourage us yet further from writing verified fakes, 
>i.e. supported in-memory implementations of things like IReactorTCP, 
>that have somewhat intricate behavior that's tedious to emulate with 
>Mock.

I'm also not a huge fan of the *unverified* mock style of testing.  I 
don't think anything says that mocks *have* to be unverified, though it 
seems they're often used that way.

The mock library that got added to the stdlib has the notion of 
constructing a mock using another object as a template.  I haven't used 
this feature, but it seems like the intent is to at least take a step 
towards verification.  It'd be nice if someone who knows more about the 
features of this library could give some examples.

In case anyone isn't clear, the problem with unverified fakes is that 
they either start out incompatible with the objects they're fakes of, or 
else they become incompatible with them over time.  Once they're 
incompatible, the tests that use them become significantly less useful, 
since they demonstrate little or nothing about what will happen when you 
try to use the code for real.

Verified fakes solve this problem by adding assertions that objects and 
their fakes have the necessary overlap in either interface or 
functionality in order for the tests using them to be valid.

Beyond that, considering the particular example presented, I wouldn't 
actually use mocks to test this.  The real object, the debugger, should 
be perfectly usable in unit tests.  It doesn't allocate or depend on 
expensive resources, it doesn't do network I/O, etc.  Mocks are perhaps 
an attractive nuisance that distract from coming up with a better test.

Jean-Paul
>Personally I'm -0.  Don't let that stop you from cooking up a patch 
>that would include it though, I might be in the minority here.
>
>-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Laurens Van Houtven]

So, mock does have an autospec mode, which is not the default, but does
result in eg methods undefined on the parent raising AttributeError.

I don't know if there's a way to generate a mock from an interface:
particularly the fact that interface methods don't have "self" in their
signature might trip it up.

cheers
lvh
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[David Reid]

On Mon, Oct 22, 2012 at 9:57 AM, Laurens Van Houtven <_...@lvh.cc> wrote:

> So, mock does have an autospec mode, which is not the default, but does
> result in eg methods undefined on the parent raising AttributeError.
>

It does, but it won't for instance know that for:
mock_agent = mock.Mock(Agent)

that mock_agent.request should return a thing that looks like a Deferred.
 So you still
end up with a bunch of setup code to enforce return types and things.


> I don't know if there's a way to generate a mock from an interface:
> particularly the fact that interface methods don't have "self" in their
> signature might trip it up.
>

Yeah, this doesn't work at all.  You end up having to always pass a thing
which provides the interface.  Or an unspecified Mock.

Of course, this isn't actually a "verified" Mock.  Because you still have
to specify all the behavior and constructing that behavior by setting
side_effect and return_value is often difficult and confusing.

So though I use mock quite a bit in my personal projects and at work I am
definitely against using it for twisted style tests.  I'd rather see some
energy put into things like a verified fake Request object and a
ResourceTraversingAgent.

-David
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Glyph]

On Oct 22, 2012, at 5:47 AM, Itamar Turner-Trauring 
 wrote:

> A testing dependency isn't quite as problematic as a regular dependency; 
> you'd only need to install it if you wanted to run Twisted's test suite, 
> which probably most users do not bother with.

This actually strikes me as a strong counter-argument for adding the dependency 
and as I'm considering it is pushing me from -0 to -1.

We already have a couple of problems running the tests when Twisted is 
system-installed and read-only to the user running the tests.  Running the 
tests is not a special thing that only developers should do in development 
configurations.  It is (well, ought to be, anyway) the way that you figure out 
if Twisted works on your system.  Every user should be encouraged to run the 
full test suite when submitting a bug report; every system integrator should 
run the tests before declaring their Twisted package working.

If we do add a dependency on mock, I would rather users have a slightly more 
inconvenient installation experience than have them unable to run the tests to 
figure out what is going on if they have a problem.  It should be imported in 
twisted/__init__.py to make sure that nobody accidentally forgets to install it 
along with Twisted.

-glyph___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 21, 2012, at 9:55 PM, Jasper St. Pierre  wrote:

> As I said, the issue I had was not "svn diff" -- I had been working on
> my fix, uploaded it to Trac, and it was a few months or so before
> someone reviewed it. I forget who it was, but the reviewer prompted me
> to make a few small style changes, flesh out a testcase, write a .news
> file, that sort of thing. I updated my source tree to pull in new
> changes from trunk, to make sure the patch that I had been working on
> didn't rot. I was frustrated when I got merge conflicts for files that
> I've never touched before.

If you can replicate the exact branch and changes you had difficulty with, I'd 
love to hear about the specifics, because this sounds like maybe it's a gotcha 
we should add to some development documentation.  It should not be possible for 
this to happen with a simple 'svn up' so I want to know what command to tell 
users they should avoid.

Feel free to reply off-list if it gets into fiddly details of subversion that 
might be off-topic.

> This is another rhetorical anecdote, I tried using git-svn when I was
> contributing to PyPy during the SVN days. It just didn't work out. I
> don't know or can't say the same for bzr-svn or hg-svn or whatever
> else cross-VCS systems there are, but I was left with a bad taste in
> my mouth, so I figured it would be more worthwhile to stick with the
> original source tool.


You say "rhetorical anecdote", I say "FUD" :).  But, perhaps you are more just 
in the class of users that need somebody like Duncan's help in order to use git 
against Twisted effectively, rather than the class of users who know the 
version control tools well enough to be able to provide that help.

> I may just be a drooling moron.


I didn't say you were a "moron", being unable to figure out git's UI for 
something is merely an indication that you probably aren't eligible for the 
Fields medal; frankly I have a great deal of difficulty with it as well.  If I 
didn't, I might have updated things myself.

I hope you'll have a better time once those instructions are updated.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Kevin Horn]

On Sun, Oct 21, 2012 at 11:05 PM, Glyph  wrote:

> On Oct 21, 2012, at 11:57 AM, Duncan McGreggor 
> wrote:
>
> I want to use git instead of svn so badly that I can taste it.
> Hopefully this provides the motivation necessary to maintain the repo
> :-)
>
>
> For what it's worth, I haven't authored a branch for Twisted with SVN in
> the last 3 years.  I use Bazaar almost exclusively and I get all the fun
> tools one generally associates with a DVCS, including offline history and a
> nice graphical revision viewer.  (One reason I am concerned about migrating
> to Git is that this will stop working; in my opinions, Git's offline GUI
> tools are far worse than Bazaar's - almost as much worse as Launchpad's
> source browser is than Github.)
>

I really wish I could figure out how to do this.  The one page on the wiki
helps a bit, but is insufficient for those not already familiar with bzr
(like me).  I've tried setting this up a couple of times, and I always end
up just giving up on it. (and no I don't recall exactly why, except for the
one time when installing bzr on windows hosed my machine and made it
unbootable...not Twisted's fault of course).


> Similarly, I do code reviews by using a local 'bzr merge'.
>
> The only weird workflow which isn't just built in to BZR-SVN is this:
> <
> http://twistedmatrix.com/trac/wiki/BazaarMirror#CommittingaBazaarbranchtoaSubversionbranch>.
>  This involves rebasing, which makes me a little sad; I wish we could
> preserve more history, but it works fine.
>
> I still *land* branches on trunk using SVN, but that takes about ten
> seconds assuming you use Combinator or svnmerge.py, so I don't see that
> being a big impediment.  You only need to worry about that if you have
> commit access anyway, so that's not most external contributors.  If the
> need to do that to land changes is preventing you from writing them in the
> first place, just let me know when you have a branch to land, and I'll do
> it for you.
>

Unless someone applied my patch, Combinator won't work on Windows.  Also,
since the great Divmod site meltdown, there's not good instructions on how
to use it (aside from the wayback machine, which is what I've been using).

I'd never heard of svnmerge.py until you mentioned it.  Are there any
instructions on how to use it with Twisted?  I'm not finding any, and I'm
reluctant to experiment since Twisted has a very specific way on
interacting with the SVN repo.


> You don't need to use SVN, you haven't needed to use SVN since git-svn
> came into existence, and we've had several threads on this list before
> about improving the Git instructions here: <
> http://twistedmatrix.com/trac/wiki/GitMirror>.  If you look at the
> history for that page, you can see that it is two years old, and originally
> created by exarkun, who is not a git user himself.
>
> So, it strikes me as a bit odd, and I am a bit dismayed that anyone would
> have been put off of by the need to use Subversion when working with
> Twisted since you can use Git or Bazaar - or, I assume, Mercurial - right
> now*.*
>

Presumably you could use Mercurial with the hggit plugin against a git
repo, but you can't use it directly against the SVN repo, as it has a bad
commit in it that hgsubversion totally chokes on:
https://bitbucket.org/durin42/hgsubversion/issue/350


> I would find it a bit more understandable if you are dismayed by the need
> to use *Trac*, which is harder to avoid when working on Twisted.  For
> various reasons - which I hope we don't have to discuss right now - we
> aren't going to *move* the project to Github any time soon, so if anyone
> reading this thread is interested in alleviating some of the pain with
> Trac,  is a good place to get involved to
> help out.  There are some pretty straightforward bugs that anyone
> interested could fix there.
>
> Frack is already up and running on twistedmatrix.com, albeit at a weird
> URL.  See, for example, <
> http://twistedmatrix.com/users/frack.twistd/ui/ticket.html?id=1956>. This
> might be useful because it is a considerably faster ticket-viewer than
> Trac, do to its somewhat more parsimonious issuance of SQL queries.
>
> -glyph
>
>
Trac has never really bothered me that much. Yes, occasionally it will do
something stupid, and it's...not fast, but I guess I'm just used to the
pain.  I'm looking forward to Frack, though.

Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Sat, Oct 20, 2012 at 4:24 PM, Duncan McGreggor
 wrote:
> Hey all,
>
> At the sprint today, Glyph mentioned that the github repo hasn't been
> updated recently and needs someone to maintain it regularly. He also
> mentioned that pull requests would be accepted from github, at which point
> I immediately volunteered to keep the repo up to date :-) (I can't bear
> using svn anymore...)
>
> I'll be putting things in place (infrastructure, scripts, etc.) to assist me
> with this, so let me know if you have any concerns, questions, ideas, etc.

So, I've got a git repo set up for trunk of svn, and for the life of
me, I can't merge it with the git repo on github.

As such, my desire is to do a force push. *However* this would break
github forks that everyone has made so far, based on twisted/twisted
(the complete list is here:
https://github.com/twisted/twisted/network/members).

Thoughts? Permission to push the button?

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Kevin Horn]

On Sun, Oct 21, 2012 at 9:45 PM, Julian Berman  wrote:

> Hi.
>
> I'd like to gauge any interest in (or resistance towards) adding mock
> (http://www.voidspace.org.uk/python/mock/mock.html) as a dependency for
> the
> test suite.
>
> In short, while I don't necessarily feel strongly about behavior vs. state
> based verification being preferred in a general sense, I think both have
> their
> place when used with sensibility. (Sorry, I know that's not saying too
> much of
> substance, but I'm trying to ward off a discussion on whether or not it
> has a
> place at all if possible).
>
> The *benefit* though for me in having mock present is that it decreases the
> lines of code necessary to write stubs and mocks. While doing so is not
> really
> that difficult anyhow, it *is* just a bit more clutter to do so without
> mock,
> and the extra 3 or 4 lines mean that in more than one instance I have found
> myself pick a different strategy than I would have because of the extra
> lines
> of code that clutter the test method.
>
> To give a specific example, as I write this I'm writing tests for #6143
> (which
> will hopefully let trial drop into a debugger on an error or failure rather
> than at the outset of a test run). To do so I want to write tests that look
> like:
>
> def test_itDebugsOnError(self):
> result = mock.Mock()
> exc_type, exc_value, tb = mock.Mock(), mock.Mock(), mock.Mock()
>
> decorated = DebugDecorator(result)
>
> with mock.patch.object(decorated, "debug") as debug:
> decorated.addError(exc_type, exc_value, tb)
>
> debug.assert_called_once_with(tb)
> result.addError.assert_called_once_with(exc_type, exc_value, tb)
>
> where I want to test that the decorated test result is being used as I
> expect
> it to, and that debug is being called. Another test will test that debug
> does
> what it's supposed to, also in isolation.
>
> Of course none of the objects I used there were very interesting, but mock
> has
> similarly terse syntax for creating mocks with attributes, return values,
> etc.
> amongst a bunch of other useful features which I'll be happy to elaborate
> on if
> anyone would like, I just had the above example at hand.
>
> To add a few more notes:
>
>  - mock is in the stdlib starting with 3.3 as unittest.mock, which as I
>understand it is the first version of Py3 for which support is planned.
> So
>really all that'd be needed would be to add mock as a dependency on 2.X.
>
>  - it's a single file with no external deps, so installation is not
> difficult,
>and it'd only be a dep for running the tests (and presumably only a
> subset
>thereof that chose to use it)
>
>  - there are other mocking libraries, but I don't like any of the others as
>much personally for various reasons.
>
>  - I'd be willing to do the small amount of work to add it if there'd be
>interest :)
>
>
> Cheers,
> Julian
>
>
I like mock, but for me, using mocks is a method of last resort.  I don't
see a lot of need for it in internal Twisted tests (except maybe in adbapi?
 I don't know what the tests for that currently look like, but it seems a
logical place).

Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Kevin Horn]

On Sun, Oct 21, 2012 at 10:00 PM, Glyph  wrote:

> On Oct 21, 2012, at 7:45 PM, Julian Berman  wrote:
>
> The *benefit* though for me in having mock present is that it decreases the
> lines of code necessary to write stubs and mocks. While doing so is not
> really
> that difficult anyhow, it *is* just a bit more clutter to do so without
> mock,
> and the extra 3 or 4 lines mean that in more than one instance I have found
> myself pick a different strategy than I would have because of the extra
> lines
> of code that clutter the test method.
>
>
> This seems like a pretty small benefit; adding a new dependency affects
> lots of people and introduces a new point of failure in the installation
> process, especially for Windows users who already have a devil of a time
> getting Twisted installed.
>

I never have much trouble, of course I always have a C compiler installed
and never use the Windows installer for Twisted any more.  The main issue I
have with installing Twisted, is that in order to use any of the command
like tools I have to go in and muck with the files (I think they just have
to be renamed...been a while since I've done it), since Twisted uses the
old distutils "script" method of installing them, rather than using
setuptools/sitribute or distutils2/packaging or whatever.

This means the various command line tools get installed (IIRC and if my
info is up to date) without file extensions, which is fine in a Unixy
environment, but don't work a'tall on Windows.


> Also I don't particularly like the testing style associated with Mock.  I
> think it might discourage us yet further from writing verified fakes, i.e.
> supported in-memory implementations of things like IReactorTCP, that have
> somewhat intricate behavior that's tedious to emulate with Mock.
>
>
My experience with mock is that when you need it it's really really
obvious, and if you don't, you shouldn't start using it, as it starts to
become a crutch.


> Personally I'm -0.  Don't let that stop you from cooking up a patch that
> would include it though, I might be in the minority here.
>
> -glyph
>
>
Kevin Horn
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[David Reid]

On Mon, Oct 22, 2012 at 10:55 AM, Duncan McGreggor <
oubiw...@twistedmatrix.com> wrote:

> On Sat, Oct 20, 2012 at 4:24 PM, Duncan McGreggor
>  wrote:
> > Hey all,
> >
> > At the sprint today, Glyph mentioned that the github repo hasn't been
> > updated recently and needs someone to maintain it regularly. He also
> > mentioned that pull requests would be accepted from github, at which
> point
> > I immediately volunteered to keep the repo up to date :-) (I can't bear
> > using svn anymore...)
> >
> > I'll be putting things in place (infrastructure, scripts, etc.) to
> assist me
> > with this, so let me know if you have any concerns, questions, ideas,
> etc.
>
> So, I've got a git repo set up for trunk of svn, and for the life of
> me, I can't merge it with the git repo on github.
>
> As such, my desire is to do a force push. *However* this would break
> github forks that everyone has made so far, based on twisted/twisted
> (the complete list is here:
> https://github.com/twisted/twisted/network/members).
>

Based on https://github.com/twisted/twisted/network

(That graph indicates that no one has actually done any substantial work
based on the old repository.)

I'm inclined to say do it.

I'm a little concerned about how you ended up with a thing that which
wasn't mergeable?  Could we start by you documenting how you created this
repo?

-David
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 22, 2012, at 11:30 AM, David Reid  wrote:

> I'm a little concerned about how you ended up with a thing that which wasn't 
> mergeable?  Could we start by you documenting how you created this repo?

Also, how did powdahound create theirs?  Understanding the distinction so that 
other git users know how to create their repos the same way, or someone else 
wants to take over maintenance, would be _highly_ useful.

-g

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Adding mock as a test suite dependency

[Julian Berman]

From: exar...@twistedmatrix.com

> Subject: Re: [Twisted-Python] Adding mock as a test suite dependency
>
> On 03:00 am, gl...@twistedmatrix.com wrote:
> >Also I don't particularly like the testing style associated with Mock.
> >I think it might discourage us yet further from writing verified fakes,
> >i.e. supported in-memory implementations of things like IReactorTCP,
> >that have somewhat intricate behavior that's tedious to emulate with
> >Mock.
>
> I'm also not a huge fan of the *unverified* mock style of testing.  I
> don't think anything says that mocks *have* to be unverified, though it
> seems they're often used that way.
>
> The mock library that got added to the stdlib has the notion of
> constructing a mock using another object as a template.  I haven't used
> this feature, but it seems like the intent is to at least take a step
> towards verification.  It'd be nice if someone who knows more about the
> features of this library could give some examples.
>
> In case anyone isn't clear, the problem with unverified fakes is that
> they either start out incompatible with the objects they're fakes of, or
> else they become incompatible with them over time.  Once they're
> incompatible, the tests that use them become significantly less useful,
> since they demonstrate little or nothing about what will happen when you
> try to use the code for real.
>
> Verified fakes solve this problem by adding assertions that objects and
> their fakes have the necessary overlap in either interface or
> functionality in order for the tests using them to be valid.
>
> Beyond that, considering the particular example presented, I wouldn't
> actually use mocks to test this.  The real object, the debugger, should
> be perfectly usable in unit tests.  It doesn't allocate or depend on
> expensive resources, it doesn't do network I/O, etc.  Mocks are perhaps
> an attractive nuisance that distract from coming up with a better test.
>
>
Well it seems I sidestepped behavior vs. state but fell into isolationist
vs integration :).

The reason I think even this was a reasonable example is because in the
code that this
will test, there is no dependence on an actual debugger whatsoever. What
this test should
be testing is that an object whose interface is irrelevant for the purpose
of the test was
handed off to another method in the case that that is expected.

In short, the isolationist view as I understand and have come to appreciate
says that
mocks (in a broader sense here since these aren't true mocks I guess)
aren't just for
cases where the real object is expensive or annoying to create – they also
remove
irrelevant details from the body of the test.

That being said though, I'm still looking (read: I have not yet looked but
will do so when I
get home) for actual examples in the test suite I can point to and say that
real, actual mocks
would have helped if that's what you'd be looking for.

To go back to your first point about verification, mock has a bunch of
things there of which
if I'm truthful I only use some of them with any regularity. The thing that
sounds like what
you're referring to is likely the `spec` argument, which will do something
like:

>>> import mock
>>> from twisted.trial.itrial import ITestCase
>>> testCase = mock.Mock(spec=ITestCase.names())
>>> testCase.run

>>> testCase.jump
Traceback (most recent call last):
  File "", line 1, in 
  File
"/usr/local/Cellar/python/2.7.3/lib/python2.7/site-packages/mock.py", line
647, in __getattr__
raise AttributeError("Mock object has no attribute %r" % name)
AttributeError: Mock object has no attribute 'jump'


As someone mentioned you also can hand it an implementor of ITestCase too
but it will then pull
off all attributes that that object has.

There's plenty more granularity, but like anything else the design of the
test requires common sense.
If the test is meant to test how a specific method on the testCase mock is
being used then assertions
on how it was called generally seem most natural.

As an alternate approach, I've learned (from a few places I think) that in
cases where I want to verify
that the places I've mocked are being used in a way that isn't going to
differ from their actual use in the
code, that a much wider scoped test that does integrate but doesn't need to
be a unit test can be helpful,
such that there are a whole bunch of isolated tests for each piece of logic
and then one integrated test
that actually does push the real object through such that anyone who does
change the way that the two
objects interacts still will have something telling them that the tests
need updating as they would if all of
the tests integrated.

Jean-Paul
> >Personally I'm -0.  Don't let that stop you from cooking up a patch
> >that would include it though, I might be in the minority here.
> >
> >-glyph
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twist

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 11:30 AM, David Reid  wrote:
>
>
> On Mon, Oct 22, 2012 at 10:55 AM, Duncan McGreggor
>  wrote:
>>
>> On Sat, Oct 20, 2012 at 4:24 PM, Duncan McGreggor
>>  wrote:
>> > Hey all,
>> >
>> > At the sprint today, Glyph mentioned that the github repo hasn't been
>> > updated recently and needs someone to maintain it regularly. He also
>> > mentioned that pull requests would be accepted from github, at which
>> > point
>> > I immediately volunteered to keep the repo up to date :-) (I can't bear
>> > using svn anymore...)
>> >
>> > I'll be putting things in place (infrastructure, scripts, etc.) to
>> > assist me
>> > with this, so let me know if you have any concerns, questions, ideas,
>> > etc.
>>
>> So, I've got a git repo set up for trunk of svn, and for the life of
>> me, I can't merge it with the git repo on github.
>>
>> As such, my desire is to do a force push. *However* this would break
>> github forks that everyone has made so far, based on twisted/twisted
>> (the complete list is here:
>> https://github.com/twisted/twisted/network/members).
>
>
> Based on https://github.com/twisted/twisted/network
>
> (That graph indicates that no one has actually done any substantial work
> based on the old repository.)
>
> I'm inclined to say do it.
>
> I'm a little concerned about how you ended up with a thing that which wasn't
> mergeable?  Could we start by you documenting how you created this repo?

Sure thing. All I did to build a git repo was the usual:

git svn clone svn://svn.twistedmatrix.com/svn/Twitsed/trunk twisted

All of my attempts to merge were using the local copy created by the
branch above (or by creating a clone of it with just one or two
revisions beyond what the github repo has, to minimize the commit #
and maximize the chance of a successful merge).

For instance:
 * git clone g...@github.com:twisted/twisted.git twisted-github; cd
twisted-github; git pull ../twisted master

(and other variations upon that theme).

I've tried using several different merge strategies; either they
couldn't complete the merge, or they resulted in gobs of conflicts.

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 11:49 AM, Glyph  wrote:
>
> On Oct 22, 2012, at 11:30 AM, David Reid  wrote:
>>
>> I'm a little concerned about how you ended up with a thing that which wasn't
>> mergeable?  Could we start by you documenting how you created this repo?
>
>
> Also, how did powdahound create theirs?  Understanding the distinction so
> that other git users know how to create their repos the same way, or someone
> else wants to take over maintenance, would be _highly_ useful.
>
> -g

Indeed, that could be illuminating.

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 12:01 PM, Duncan McGreggor
 wrote:
> On Mon, Oct 22, 2012 at 11:30 AM, David Reid  wrote:
>>
>>
>> On Mon, Oct 22, 2012 at 10:55 AM, Duncan McGreggor
>>  wrote:
>>>
>>> On Sat, Oct 20, 2012 at 4:24 PM, Duncan McGreggor
>>>  wrote:
>>> > Hey all,
>>> >
>>> > At the sprint today, Glyph mentioned that the github repo hasn't been
>>> > updated recently and needs someone to maintain it regularly. He also
>>> > mentioned that pull requests would be accepted from github, at which
>>> > point
>>> > I immediately volunteered to keep the repo up to date :-) (I can't bear
>>> > using svn anymore...)
>>> >
>>> > I'll be putting things in place (infrastructure, scripts, etc.) to
>>> > assist me
>>> > with this, so let me know if you have any concerns, questions, ideas,
>>> > etc.
>>>
>>> So, I've got a git repo set up for trunk of svn, and for the life of
>>> me, I can't merge it with the git repo on github.
>>>
>>> As such, my desire is to do a force push. *However* this would break
>>> github forks that everyone has made so far, based on twisted/twisted
>>> (the complete list is here:
>>> https://github.com/twisted/twisted/network/members).
>>
>>
>> Based on https://github.com/twisted/twisted/network
>>
>> (That graph indicates that no one has actually done any substantial work
>> based on the old repository.)
>>
>> I'm inclined to say do it.
>>
>> I'm a little concerned about how you ended up with a thing that which wasn't
>> mergeable?  Could we start by you documenting how you created this repo?
>
> Sure thing. All I did to build a git repo was the usual:
>
> git svn clone svn://svn.twistedmatrix.com/svn/Twitsed/trunk twisted
>
> All of my attempts to merge were using the local copy created by the
> branch above (or by creating a clone of it with just one or two
> revisions beyond what the github repo has, to minimize the commit #
> and maximize the chance of a successful merge).
>
> For instance:
>  * git clone g...@github.com:twisted/twisted.git twisted-github; cd
> twisted-github; git pull ../twisted master
>
> (and other variations upon that theme).
>
> I've tried using several different merge strategies; either they
> couldn't complete the merge, or they resulted in gobs of conflicts.
>
> d

So I just tried something else:

git pull -s recursive -Xtheirs ../twisted master

since this was run in the github master, the "theirs" is the svn clone
master, and forcing the adoption of "theirs" resulted in many fewer
conflicts. Hundreds of fewer conflicts, maybe?

Looking into this to see if anything was broken by this approach...

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 22, 2012, at 10:53 AM, Kevin Horn  wrote:

> 
> 
> On Sun, Oct 21, 2012 at 11:05 PM, Glyph  wrote:
> On Oct 21, 2012, at 11:57 AM, Duncan McGreggor  
> wrote:
> 
>> I want to use git instead of svn so badly that I can taste it.
>> Hopefully this provides the motivation necessary to maintain the repo
>> :-)
> 
> 
> For what it's worth, I haven't authored a branch for Twisted with SVN in the 
> last 3 years.  I use Bazaar almost exclusively and I get all the fun tools 
> one generally associates with a DVCS, including offline history and a nice 
> graphical revision viewer.  (One reason I am concerned about migrating to Git 
> is that this will stop working; in my opinions, Git's offline GUI tools are 
> far worse than Bazaar's - almost as much worse as Launchpad's source browser 
> is than Github.)
> 
> I really wish I could figure out how to do this.  The one page on the wiki 
> helps a bit, but is insufficient for those not already familiar with bzr 
> (like me).  I've tried setting this up a couple of times, and I always end up 
> just giving up on it.

Let me keep it super short and sweet for you:

C:\PROJEC~1> bzr branch http://svn.twistedmatrix.com/bzr/Twisted/trunk Twisted
C:\PROJEC~1> cd Twisted

as many times as desired,

C:\PROJEC~1\TWISTED> hack hack hack
C:\PROJEC~1\TWISTED> C:\python27\python.exe bin\trial twisted
C:\PROJEC~1\TWISTED> bzr commit

Review time!

C:\PROJEC~1\TWISTED> bzr send -o - > my.patch

Stick my.patch on a ticket and you're good to go.  No need for combinator, or 
virtualenv, or subversion (not even bzr-svn, we did that part for you), or even 
a C compiler, assuming the feature you're working on doesn't need one.

If any of this isn't covered in the wiki page then please update it.  And 
please feel free to ask more questions - if specific version control or 
workflow issues are preventing anyone from working on Twisted then it is 
definitely on-topic for this list and I will be happy to provide answers and 
update development documentation.

> (and no I don't recall exactly why, except for the one time when installing 
> bzr on windows hosed my machine and made it unbootable...not Twisted's fault 
> of course).

Can we just agree that you had a virus and that this had nothing to do with 
anything in this thread?  Even if that's not true I think it might be long-term 
more mentally healthy for you to believe :-)

> Similarly, I do code reviews by using a local 'bzr merge'.
> 
> The only weird workflow which isn't just built in to BZR-SVN is this:
> .
>   This involves rebasing, which makes me a little sad; I wish we could 
> preserve more history, but it works fine.
> 
> I still land branches on trunk using SVN, but that takes about ten seconds 
> assuming you use Combinator or svnmerge.py, so I don't see that being a big 
> impediment.  You only need to worry about that if you have commit access 
> anyway, so that's not most external contributors.  If the need to do that to 
> land changes is preventing you from writing them in the first place, just let 
> me know when you have a branch to land, and I'll do it for you.
> 
> Unless someone applied my patch, Combinator won't work on Windows.  Also, 
> since the great Divmod site meltdown, there's not good instructions on how to 
> use it (aside from the wayback machine, which is what I've been using).
> 
> I'd never heard of svnmerge.py until you mentioned it.  Are there any 
> instructions on how to use it with Twisted?  I'm not finding any, and I'm 
> reluctant to experiment since Twisted has a very specific way on interacting 
> with the SVN repo.

I guess I should test this out myself at least once, but my understanding is 
that you just do svnmerge.py --bidirectional -S the-branch-you-want-to-merge in 
trunk.  You can test this out for yourself though, since svnmerge.py is loudly 
advertised as "commit-free": you always have to do the commit yourself.

More info here: .

If we can ever upgrade to a version of SVN on the server that supports 
merge-tracking, the need for either of these tools will go away since a plain 
'svn merge ../branches/branchname' will do the right thing.  Any volunteer 
sysadmins want to take the opportunity to crawl out of the woodwork?  (Please?)

But again: if you have trouble with this part, please just drop an email to the 
list and I will do it for you.  Do not let this minor step be an impediment to 
contributing to Twisted.

> You don't need to use SVN, you haven't needed to use SVN since git-svn came 
> into existence, and we've had several threads on this list before about 
> improving the Git instructions here: 
> .  If you look at the history 
> for that page, you can see that it is two years old, and originally created 
> by exarkun, who is not a git user himself.
> 
> So, it strikes me as a bit 

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 22, 2012, at 12:01 PM, Duncan McGreggor  
wrote:

> Sure thing. All I did to build a git repo was the usual:
> 
> git svn clone svn://svn.twistedmatrix.com/svn/Twitsed/trunk twisted

The spelling error in this command makes me think that maybe you didn't copy 
the command exactly from wherever you did it? ;-)

-g___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 22, 2012, at 12:01 PM, Duncan McGreggor  
wrote:

> ... the local copy ...

I should also say that I think it's very important to set up a documented, 
automated process, ideally on the twistedmatrix.com infrastructure somewhere, 
that will do the pull and update and stuff.  There's already a git mirror on 
wolfwood in /var/www/git/Twisted.  I have no idea why it's not being 
automatically updated.

For example, there's a post-commit hook that updates the bzr mirror, so it's 
always up to date.  See wolfwood:/svn/Twisted/hooks/post-commit for the details 
of how that works.

A post-commit hook might not be appropriate for git; so you might want to queue 
up changes for a cron job.

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 12:23 PM, Glyph  wrote:
>
> On Oct 22, 2012, at 12:01 PM, Duncan McGreggor 
> wrote:
>
> Sure thing. All I did to build a git repo was the usual:
>
> git svn clone svn://svn.twistedmatrix.com/svn/Twitsed/trunk twisted
>
>
> The spelling error in this command makes me think that maybe you didn't copy
> the command exactly from wherever you did it? ;-)

That's correct -- I manually typed it in the email (I'm using xterm on
stumpwm in XQuartz, and haven't gotten bidirectional copy/paste set up
yet).

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 12:30 PM, Glyph  wrote:
> On Oct 22, 2012, at 12:01 PM, Duncan McGreggor 
> wrote:
>>
>> ... the local copy ...
>>
>
> I should also say that I think it's very important to set up a documented,
> automated process,

Agreed.

> ideally on the twistedmatrix.com infrastructure
> somewhere, that will do the pull and update and stuff.

Excellent. I'll check to see if I have access to these.

> There's already a
> git mirror on wolfwood in /var/www/git/Twisted.

Now *that's* good information to have ;-)

> I have no idea why it's not
> being automatically updated.
>
> For example, there's a post-commit hook that updates the bzr mirror, so it's
> always up to date.  See wolfwood:/svn/Twisted/hooks/post-commit for the
> details of how that works.

Sweet. This is the sort of thing I need.

d

> A post-commit hook might not be appropriate for git; so you might want to
> queue up changes for a cron job.
>
> -glyph
>
>
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Duncan McGreggor]

On Mon, Oct 22, 2012 at 12:04 PM, Duncan McGreggor
 wrote:
> On Mon, Oct 22, 2012 at 12:01 PM, Duncan McGreggor
>  wrote:
>> On Mon, Oct 22, 2012 at 11:30 AM, David Reid  wrote:
>>>
>>>
>>> On Mon, Oct 22, 2012 at 10:55 AM, Duncan McGreggor
>>>  wrote:

 On Sat, Oct 20, 2012 at 4:24 PM, Duncan McGreggor
  wrote:
 > Hey all,
 >
 > At the sprint today, Glyph mentioned that the github repo hasn't been
 > updated recently and needs someone to maintain it regularly. He also
 > mentioned that pull requests would be accepted from github, at which
 > point
 > I immediately volunteered to keep the repo up to date :-) (I can't bear
 > using svn anymore...)
 >
 > I'll be putting things in place (infrastructure, scripts, etc.) to
 > assist me
 > with this, so let me know if you have any concerns, questions, ideas,
 > etc.

 So, I've got a git repo set up for trunk of svn, and for the life of
 me, I can't merge it with the git repo on github.

 As such, my desire is to do a force push. *However* this would break
 github forks that everyone has made so far, based on twisted/twisted
 (the complete list is here:
 https://github.com/twisted/twisted/network/members).
>>>
>>>
>>> Based on https://github.com/twisted/twisted/network
>>>
>>> (That graph indicates that no one has actually done any substantial work
>>> based on the old repository.)
>>>
>>> I'm inclined to say do it.
>>>
>>> I'm a little concerned about how you ended up with a thing that which wasn't
>>> mergeable?  Could we start by you documenting how you created this repo?
>>
>> Sure thing. All I did to build a git repo was the usual:
>>
>> git svn clone svn://svn.twistedmatrix.com/svn/Twitsed/trunk twisted
>>
>> All of my attempts to merge were using the local copy created by the
>> branch above (or by creating a clone of it with just one or two
>> revisions beyond what the github repo has, to minimize the commit #
>> and maximize the chance of a successful merge).
>>
>> For instance:
>>  * git clone g...@github.com:twisted/twisted.git twisted-github; cd
>> twisted-github; git pull ../twisted master
>>
>> (and other variations upon that theme).
>>
>> I've tried using several different merge strategies; either they
>> couldn't complete the merge, or they resulted in gobs of conflicts.
>>
>> d
>
> So I just tried something else:
>
> git pull -s recursive -Xtheirs ../twisted master
>
> since this was run in the github master, the "theirs" is the svn clone
> master, and forcing the adoption of "theirs" resulted in many fewer
> conflicts. Hundreds of fewer conflicts, maybe?
>
> Looking into this to see if anything was broken by this approach...
>
> d

It seems that the topfiles were mostly affected by this. Some deleted
files git didn't know what do to with. But then I noticed that other
files that had been modified weren't included in the change set.

*sighs*

As a sanity check, I did a local rsync, and sure enough, there are a
bunch of files that didn't get merged using the strategy above that
were changed in the svn repo.

I'll put this part of the effort on hold, and take a look at the repo
mirror that Glyph pointed me to in his most recent email...

d

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Lucas Taylor]

On Oct 21, 2012, at 11:05 PM, Glyph wrote:

>> 
>> The few times I've tried to contributed to Twisted, svn was actually a big 
>> barrier. Trying to update my patches so that I'm sure the tests pass on 
>> trunk produced mysterious merge conflicts in files I've never touched. Maybe 
>> I'm bad at svn, but it's never worked well for me.
> 
> Why aren't you just using git for local development then?  You don't have 
> commit access, so you should never need to touch an svn client other than git 
> if you don't feel like it.
> 
> This is not entirely a rhetorical question.  We have always tried to be 
> accommodating to DVCS users, providing instructions and repeated requests for 
> both a plain git and/or a github ambassador to keep svn nicely synchronized 
> and reduce the friction required for users of those tools to make 
> contributions.  If the documentation we've offered on 
>  is in any way incorrect or 
> non-optimal, please don't hesitate to say exactly what would be better.  If 
> you need wiki edit permission to update the page, I'll gladly give it to you.
> 
> -glyph


I think there are a few issues with the documentation, from the standpoint of 
an infrequent contributor:

• It appears that you have to go "all in" with svn if you want to 
contribute, when that isn't actually the case

•  is not terribly easy to 
find.
• It does come up in search, but is otherwise not easily accessible 
when you're spelunking for info on how to contribute
• The page with the links has it as a parenthetical aside 


• Casual contributors should have a different story than core committers, 
but the distinction isn't always prominent
•  makes this 
distinction, which is good
•  does not.


For what it's worth, I've been using Mercurial patch queues to manage a couple 
of infrequent, small contributions. It works pretty well and doesn't rely on 
svn history or an svn bridge. That's not terribly interesting, but the point is 
that there are probably other workflows that are effective and it would be 
useful if they could be documented and shared easily.

I created a ticket to address some of these points and carry on the docs 
discussion elsewhere. If it seems like a good idea I'll work on updating the 
wiki.
http://twistedmatrix.com/trac/ticket/6154


Lucas Taylor



___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] git repo maintenance

[Kevin Horn]

On Mon, Oct 22, 2012 at 2:22 PM, Glyph  wrote:

>
> On Oct 22, 2012, at 10:53 AM, Kevin Horn  wrote:
>
>
> On Sun, Oct 21, 2012 at 11:05 PM, Glyph  wrote:
>>
>>
>> For what it's worth, I haven't authored a branch for Twisted with SVN in
>> the last 3 years.  I use Bazaar almost exclusively and I get all the fun
>> tools one generally associates with a DVCS, including offline history and a
>> nice graphical revision viewer.  (One reason I am concerned about migrating
>> to Git is that this will stop working; in my opinions, Git's offline GUI
>> tools are far worse than Bazaar's - almost as much worse as Launchpad's
>> source browser is than Github.)
>>
>
> I really wish I could figure out how to do this.  The one page on the wiki
> helps a bit, but is insufficient for those not already familiar with bzr
> (like me).  I've tried setting this up a couple of times, and I always end
> up just giving up on it.
>
>
> Let me keep it super short and sweet for you:
>
> C:\PROJEC~1> bzr branch http://svn.twistedmatrix.com/bzr/Twisted/trunkTwisted
> C:\PROJEC~1> cd Twisted
>
> as many times as desired,
>
> C:\PROJEC~1\TWISTED> hack hack hack
>
> C:\PROJEC~1\TWISTED> C:\python27\python.exe bin\trial twisted
>
> C:\PROJEC~1\TWISTED> bzr commit
>
>
> Review time!
>
> C:\PROJEC~1\TWISTED> bzr send -o - > my.patch
>
> Stick my.patch on a ticket and you're good to go.  No need for combinator,
> or virtualenv, or subversion (not even bzr-svn, we did that part for you),
> or even a C compiler, assuming the feature you're working on doesn't need
> one.
>
> If any of this isn't covered in the wiki page then please update it.  And
> please feel free to ask more questions - if specific version control or
> workflow issues are preventing anyone from working on Twisted then it is
> definitely on-topic for this list and I will be happy to provide answers
> and update development documentation.
>
>
See that should totally be on a wiki page someplace.

I'd be happy to put it up there, but I don't have edit permissions on that
page (or any of them?) apparently...


> (and no I don't recall exactly why, except for the one time when
> installing bzr on windows hosed my machine and made it unbootable...not
> Twisted's fault of course).
>
>
> Can we just agree that you had a virus and that this had nothing to do
> with anything in this thread?  Even if that's not true I think it might be
> long-term more mentally healthy for you to believe :-)
>
>
Actually I know exactly why this happened, and it's because Windows has a
hard limit on the number of "icon overlays" you can add to Explorer.  I
installed TortoiseBzr along with bzr, and went over that limit.  This by
itself is not such a big deal, but it turns out that the failure behavior
of this particular issue is NOT BOOTING ANY MORE. (stupid Windows)

(FYI, I've since installed bzr again, and have had no similar problems.)

(also FYI, I haven't had a virus/spyware on a windows machine that I owned
in more than 10 years..the trick is renaming the
iexplore.exe executable...)

But aside from that, the couple of times I've tried messing around with bzr
I end up going in circles in their documentation, can't decide what I
should be doing, decide I don't have time to mess with it and just go back
to SVN (which is painful).  Of course by that time I've usually gotten
distracted and I never finish whatever it was I was working on...

Mostly these days I just bang my head against translating the Lore docs
into Sphinx (yes, I'm _still_ working on that).

Unless someone applied my patch, Combinator won't work on Windows.  Also,
> since the great Divmod site meltdown, there's not good instructions on how
> to use it (aside from the wayback machine, which is what I've been using).
>
> I'd never heard of svnmerge.py until you mentioned it.  Are there any
> instructions on how to use it with Twisted?  I'm not finding any, and I'm
> reluctant to experiment since Twisted has a very specific way on
> interacting with the SVN repo.
>
>
> I guess I should test this out myself at least once, but my understanding
> is that you just do svnmerge.py --bidirectional -S
> the-branch-you-want-to-merge in trunk.  You can test this out for yourself
> though, since svnmerge.py is loudly advertised as "commit-free": you always
> have to do the commit yourself.
>
> More info here: .
>
>
Hmmm...interesting.


> If we can ever upgrade to a version of SVN on the server that supports
> merge-tracking, the need for either of these tools will go away since a
> plain 'svn merge ../branches/branchname' will do the right thing.  Any
> volunteer sysadmins want to take the opportunity to crawl out of the
> woodwork?  (Please?)
>
>
I had no idea that Twisted was still using such an old version.  I was
under the impression that the hackery that Combinator used was incompatible
with the new merge tracking and that's why it wasn't being used (because it
would screw up those still using C

Re: [Twisted-Python] git repo maintenance

[Glyph]

On Oct 22, 2012, at 4:54 PM, Kevin Horn  wrote:

> On Mon, Oct 22, 2012 at 2:22 PM, Glyph  wrote:
> 
> On Oct 22, 2012, at 10:53 AM, Kevin Horn  wrote:
>> 
>> On Sun, Oct 21, 2012 at 11:05 PM, Glyph  wrote:
>> 
>> For what it's worth, I haven't authored a branch for Twisted with SVN in the 
>> last 3 years.  I use Bazaar almost exclusively and I get all the fun tools 
>> one generally associates with a DVCS, including offline history and a nice 
>> graphical revision viewer.  (One reason I am concerned about migrating to 
>> Git is that this will stop working; in my opinions, Git's offline GUI tools 
>> are far worse than Bazaar's - almost as much worse as Launchpad's source 
>> browser is than Github.)
>> 
>> I really wish I could figure out how to do this.  The one page on the wiki 
>> helps a bit, but is insufficient for those not already familiar with bzr 
>> (like me).  I've tried setting this up a couple of times, and I always end 
>> up just giving up on it.
> 
> Let me keep it super short and sweet for you:
> 
> C:\PROJEC~1> bzr branch http://svn.twistedmatrix.com/bzr/Twisted/trunk Twisted
> C:\PROJEC~1> cd Twisted
> 
> as many times as desired,
> 
> C:\PROJEC~1\TWISTED> hack hack hack
> C:\PROJEC~1\TWISTED> C:\python27\python.exe bin\trial twisted
> C:\PROJEC~1\TWISTED> bzr commit
> 
> Review time!
> 
> C:\PROJEC~1\TWISTED> bzr send -o - > my.patch
> 
> Stick my.patch on a ticket and you're good to go.  No need for combinator, or 
> virtualenv, or subversion (not even bzr-svn, we did that part for you), or 
> even a C compiler, assuming the feature you're working on doesn't need one.
> 
> If any of this isn't covered in the wiki page then please update it.  And 
> please feel free to ask more questions - if specific version control or 
> workflow issues are preventing anyone from working on Twisted then it is 
> definitely on-topic for this list and I will be happy to provide answers and 
> update development documentation.
> 
> 
> See that should totally be on a wiki page someplace.
> 
> I'd be happy to put it up there, but I don't have edit permissions on that 
> page (or any of them?) apparently...

You're a trac admin now.  Enjoy; don't mess anything up too bad.

>  
>> (and no I don't recall exactly why, except for the one time when installing 
>> bzr on windows hosed my machine and made it unbootable...not Twisted's fault 
>> of course).
> 
> Can we just agree that you had a virus and that this had nothing to do with 
> anything in this thread?  Even if that's not true I think it might be 
> long-term more mentally healthy for you to believe :-)
> 
> 
> Actually I know exactly why this happened, and it's because Windows has a 
> hard limit on the number of "icon overlays" you can add to Explorer.  I 
> installed TortoiseBzr along with bzr, and went over that limit.  This by 
> itself is not such a big deal, but it turns out that the failure behavior of 
> this particular issue is NOT BOOTING ANY MORE. (stupid Windows)
> 
> (FYI, I've since installed bzr again, and have had no similar problems.)
> 
> (also FYI, I haven't had a virus/spyware on a windows machine that I owned in 
> more than 10 years..the trick is renaming the iexplore.exe 
> executable...)
> 
> But aside from that, the couple of times I've tried messing around with bzr I 
> end up going in circles in their documentation, can't decide what I should be 
> doing, decide I don't have time to mess with it and just go back to SVN 
> (which is painful).  Of course by that time I've usually gotten distracted 
> and I never finish whatever it was I was working on...
> 
> Mostly these days I just bang my head against translating the Lore docs into 
> Sphinx (yes, I'm _still_ working on that).

Glad to hear this is still moving along, however glacially.

>> Unless someone applied my patch, Combinator won't work on Windows.  Also, 
>> since the great Divmod site meltdown, there's not good instructions on how 
>> to use it (aside from the wayback machine, which is what I've been using).
>> 
>> I'd never heard of svnmerge.py until you mentioned it.  Are there any 
>> instructions on how to use it with Twisted?  I'm not finding any, and I'm 
>> reluctant to experiment since Twisted has a very specific way on interacting 
>> with the SVN repo.
> 
> I guess I should test this out myself at least once, but my understanding is 
> that you just do svnmerge.py --bidirectional -S the-branch-you-want-to-merge 
> in trunk.  You can test this out for yourself though, since svnmerge.py is 
> loudly advertised as "commit-free": you always have to do the commit yourself.
> 
> More info here: .
> 
> 
> Hmmm...interesting.
>  
> If we can ever upgrade to a version of SVN on the server that supports 
> merge-tracking, the need for either of these tools will go away since a plain 
> 'svn merge ../branches/branchname' will do the right thing.  Any volunteer 
> sysadmins want to take the opportunity to crawl o