Re: [Twisted-Python] git?

2014-03-20 Thread Chris Withers

On 13/03/2014 19:38, Glyph Lefkowitz wrote:

On Mar 12, 2014, at 11:53 PM, Chris Withers mailto:ch...@simplistix.co.uk>> wrote:


Not to be too contentious, but when do you reckon you guys will switch
the main repo to git?


Just to be clear about the nature of my other answers: we do not
"reckon" such a thing will happen; we have no estimates.  Things get
done because volunteers do them.  You could be just such a volunteer :).


I've read up on the thread and it's interesting to note that Mike Bayer 
has poured a huge amount of effort into doing the move for SQLAlchemy, 
producing some great tools in the process. I believe he now has 3 git 
repos that keep each other in sync, as well as accepting pull requests 
via both bitbucket and github.


I asked him about it and checked that it was okay to forward on his 
reply, please find it attached.


Hope this helps,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--- Begin Message ---
well we were on mercurial before git, so our SVN migration was to mercurial, 
though it’s just as simple moving from SVN to git directly, we did that at work.

However: when I migrate VCS’s, I usually need to alter the migration utilities 
to support the following features that people usually don’t seem to care about:

1. author mapping.  Ensure that author names/emails from the old system are 
updated in the new system the way we want them to be.

2. commit message rewriting.   We make a lot of use of revision numbers in 
commit messages (e.g. like r1234), so when we do the migration we like to 
rewrite the commit messages with the new numbers as well (this of course means 
the transfer system needs to have those numbers available up front).

3. as far as tags and branches, I’m non-negotiable in that these must transfer 
*exactly* with no shenanigans, naming changes, loss of history, etc..  hg-git 
has some silly restrictions that it doesn’t support hg branches, only 
“bookmarks” which nobody uses, this is because hg-git is trying to do a 
hg<->git bidirectional workflow, which is ludicrous.  I don’t need that, so I 
wrote https://bitbucket.org/zzzeek/hggitonce based on it to do what I want.

When you move VCS’s, you need to make sure you capture a file that is the 
translation map from old to new revision identifiers.  you then use this map to 
rewrite all of the issues and comments in your issue tracking system to refer 
to the new numbers.   Using trac, this is obviously pretty easy since you just 
access the database directly and do the work.I’ve done this twice with trac 
- once with svn-> hg, and then with hg->git.

As far as github for issue tracking, you have much bigger issues there, since 
github does not allow a pure import of issues which include original timestamps 
and author names.  I tried to ask them about that once and I got a pretty 
dismissive response from some sleepy 20 year old kid.Again, it’s not an 
option to lose the timestamps on your issues nor to lose author names for 
people who have accounts in github.

That’s why I think bitbucket’s system is superior in many ways:

1. its workflow is much more similar to trac and is easier to map
2. their support is 150% top notch and I have direct email access to several 
people there 
3. they have a full blown import/export system that accepts author names and 
timestamps, you can rewrite your issue database as many times as you like.

To transfer issues from trac to bitbucket I wrote bbutils: 
https://bitbucket.org/zzzeek/bbutils.   It’s got some quirks but does the job.  
 When you transfer your issues to bitbucket, you need to be careful which 
author names you take over as a lot of them aren’t on bitbucket, and also you 
need to run through the issues about 30 minutes after import and clear the 
“spam” flags that their spam bot will invariably set up.  the BB devs can do 
this for you, but so I don’t have to bother them I wrote a “spam” command in 
bbutils that does this for you.

I’m not sure how twisted handles spam with their trac install, that’s 
ultimately the reason I had to move.  the spammers found me, and none of trac’s 
underdocumented and obtuse spam tools could do anything about it.super glad 
I don’t host any more applications or email anymore.

On Mar 13, 2014, at 4:56 AM, Chris Withers  wrote:

> Hi Mike,
> 
> How much of what you did with sqlalchemy is a recipe that the Twisted 
> guys could follow?
> 
> Chris
> 
> 
>  Original Message 
> Subject: Re: [Twisted-Python] git?
> Date: Thu, 13 Mar 2014 15:14:53 +0800
> From: HawkOwl 
> Reply-To: Twisted general discussion 
> To: twisted-python@twistedmatrix.com
> 
> Signed PGP part
> Hi Chris,
> 
> I can assure you this topic has come up many times - and unless we
> have volunteers that can manage to get the several thousand tickets
> with comment history into GitHub (which I'm sure that nobody wants to
> get tied to when you have a workflow al

Re: [Twisted-Python] git?

2014-03-20 Thread Jonas Brunsgaard
On Sun, Mar 16, 2014 at 9:12 PM, Glyph  wrote:

>
> On Mar 16, 2014, at 12:31 AM, Jonathan Ballet  wrote:
>
> Hi Glyph,
>
> On Thu, Mar 13, 2014 at 12:35:17PM -0700, Glyph Lefkowitz wrote:
>
>
> If someone would like to turn this list into a wiki page under <
> https://twistedmatrix.com/trac/wiki/Infrastructure> that would be great,
> so it could be updated with anything I've forgotten. Right now there's the
> beginnings of a SwitchToBazaar which should probably be deleted, since
> we're not going to do that.
>
>
> I don't have edit permissions on the wiki, so I took the list of stuff
> you mentionned here and made a wiki page joined to this email.
>
>
> What's your username?  The only reason we even have edit permissions is to
> prevent spamming, anyone may ask for edit permission at any time :-).
>

I would like edit permissions too, my username is brunsgaard.


> Compared to the SwitchToBazar page, here are the things which are
> missing from your email - I don't know how relevant they are though:
>
> * mailer post-commit hook
>
>
> Yeah, we probably need this.  It seems like this ought to be pretty
> trivial to set up in git though :-).
>
> * the release scripts
>
>
> Oh, good point.  These rely fairly lightly on svn, but the dependency is
> there.
>
> This would be a good place to start.  Unfortunately, since tagging works
> differently in svn and git, I don't think we can simply start doing the
> release out of git without a repository to push to.  If I'm wrong about
> this, so much the better, and we could actually start having release
> managers use git if they like :).  Regardless, all the code to do so could
> be tested and landed as a normal development task with no administrative
> blockers, so this might be a good place for someone interested in moving
> the process along to start.
>
> * the developer documentation (I guess that should be done)
>
>
> The developer documentation is already so bad (as Adi Roiban has pointed
> out) that it wouldn't make sense to block migrating to git on a
> comprehensive upgrade.
>
> * figure the version number from Git instead of Subversion
>
>
> This would be an even more straightforward patch to Twisted, in
> twisted.python.versions.
>
> * decide what to do with Combinator
>
>
> I think Combinator is an evolutionary dead end at this point.  Tools like
> virtualenv, virtualenvwrapper, pyenv,
>
> There might be still some editing to do but that could be a start.
>
>
> I've deleted the SwitchToBazaar page and, for now, uploaded your proposal
> at .
>  Hopefully someone (maybe me) can give you edit permission as soon as you
> announce your username :).
>
> Thanks for your contribution,
>
> -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