On Jun 4, 2013, at 2:49 AM, tds...@gmail.com wrote:

> Hi,
> 
> what about Bitbucket (www.bitbucket.org) and mercurial ?
> 
> Don't they provide the same features ?
> 
> I'm asking because we are in Python land. ;-)

BitBucket isn't as slick as GitHub.

Mercurial isn't as well known, and the storage isn't as optimal.

SqlAlchemy recently migrated from hg to git -- here is Mike Bayer's rationale:

        http://www.sqlalchemy.org/blog/#sqlalchemy-migrated-to-git

It's trivial to clone a repo with git.  Also, I believe that if you configure a 
working repository to follow all the upstream changes, you essentially have a 
full clone.  So if the primary ever went down, one of the package maintainers 
could instantly become the new upstream.

I use git+github for all my open source work, and subversion for private stuff 
-- only because i'm too lazy to set up a remote hg repo.  Git was hard to get 
used to, and can be difficult at times, but it's a significantly better 
experience.  The biggest win with git for me, is that you have offline commits. 
 I've found myself forced to be online for a svn commit too many times ( while 
restructuring projects ).  git is more flexible -- you can do everything 
locally and never have to push to the server until you're ready ( no more "part 
1 of 3" repo commits ).  then you can squash all the commits into a single 
server push.

The code review process on git and github is great; and the fork + merge model 
is much easier than working with SVN. 

someone mentioned `rebase` and `squash`.  

these articles do a much better job at describing it than i can:  
        http://git-scm.com/book/en/Git-Branching-Rebasing
        
http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

in a nutshell, rebase allows you to start replaying commits onto a working 
copy.  you can then pick and choose which are kept, tossed, or merged.  it's 
basically a way to rewrite or replay history.  

the only downside to git, is that once something goes onto the server... it's 
there for good.  it's possible to rebase a repo back to a specific commit , 
then replay without specific commits, and "push -f" to overwrite the history... 
but if anyone updated against the server, those commits will come back and 
haunt you.  over and over and over again.  

there's also a great plugin called "git flow"  
http://nvie.com/posts/a-successful-git-branching-model/    
https://github.com/nvie/gitflow  

it's just some shell scripts that help automate how you organize your branches 
for fixing issues.




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

Reply via email to