[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How does team maintenace of python module works?

On Feb 21, 2013, at 12:15 PM, Chow Loong Jin wrote:

>I'll admit that git isn't the simplest one, the others are not perfect either.
>To this day, I can't for the life of me figure out how to use CVS. Thank
>goodness git-cvsimport works.

Of course, CVS is 20+ years old so its ancient model is working against you.

>SVN is simple enough, but so is git when used with only linear history. But
>let's not forget the horrible hack that is svn tagging/branching.

True, but also not much of a mental stretch when you realize it's just
creating new directories in the repo.

>Bzr is simple enough as well, but $deity help you when you get incompatible
>pack format repositories

Mostly not an issue any more, since 2a format has been the only sane format to
use for a few years now.  Yes, you do run into old branch formats now and
then.  Sigh.

>, or when bzr suddenly decides that your branches have diverged for no
>apparent reason whatsoever.

I agree with this one.  It's a real problem with UDD when you have both an
upstream branch (e.g. lp:foo) and a packaging branch (e.g. ubuntu:foo).

>At least with git, you know when you've rewritten history -- you're no longer
>on the same commit.

#9 on Steve Bennett's list is right on target IMHO, but I've had this
discussion so many times before, I don't have much energy for it again.

9. Git history is a bunch of lies
The primary output of development work should be source code. Is a
well-maintained history really such an important by-product? Most of the
arguments for rebase, in particular, rely on aesthetic judgments about “messy
merges” in the history, or “unreadable logs”. So rebase encourages you to lie
in order to provide other developers with a “clean”, “uncluttered”
history. Surely the correct solution is a better log output that can filter
out these unwanted merges.


Attachment: signature.asc
Description: PGP signature

Reply to: