kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #04332
Re: Distributed Version Control
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"Lorenzo" <lomarcan@...>
-
Date:
Mon, 22 Feb 2010 07:59:16 -0000
-
In-reply-to:
<4B80089E.7010505@...>
-
User-agent:
eGroups-EW/0.82
> Why not GIT:
>
> 1) Git *is* bloated,
Somewhat agree :P
> 2) is hard to learn for newbies,
I didn't see any major difficulties (behind the intrinsics of VC)
> 3) is written in linux like C, there is no reason to use C for applications.
I could disagree with just how many issues you want with the 'no reason forC in application' but holy wars are not proficuous :D Anyway since IIRC git is a son-of-Torvalds I'd expect it to be wrote in a linux-like C :P
> 4) doesn't install well and run simply on windows (MSYS or CYGWIN
> required) I don't we should inflict CYGWIN on anyone.
Can't comment on this issue... OTOH for some reason on my box it didn't build the manpages (probably some missing tool)
> 5) is not common to both sourceforge and launchpad.net (bazaar is)
Can be an important logistic issue, I agree with that.
> 6) does not have a powerful python repo manipulation API, like bazaar's.
Maybe it just has some powerful C repo manipulation API (just joking :D). As an aside: what do you need a repo manipulation API for?
> 7) is not supported by folks with a culture of friendliness like bazaar is.
No idea on that
> 8) has weird revision IDs
git revision ids are actually LESS weirder than CVS ones :D I agree that from an id it's VERY difficult (i.e. impossible without a query) to decide ifit is before or after another one... which probably gave birth to the 'bisect' facility...
> 9) GITs bridging to svn in not unique.
Never investigated on that...
> 10) I don't like GIT, mostly because of 1-8.
Well, I could say that I don't like anything which uses python for the samereason:P:P I don't even have it installed and it react poorly with stow-alike package management. And anyway I'd just prefer staying with svn, but only because I know it better that any other VCS (BTW I've a parallel repo feeding from the main one).
> DVCS *software speed* is not really a concern because the traffic at the
> REPO site is often the bottleneck in any transaction.
Usually, yes, but that's mostly for non distributed VC. A DVCS only uses the REPO for push and pulls (I'm using git terminology), all the queries run on the local copy. Actually the reason I don't like DVCS is exactly that you need a FULL local copy of the repository (with 20 users and big repositories that's a lot of disk, but that's my environment issue).
> My long term vision for the footprint retrieval interface is best served
> by folks becoming familiar with bazaar. The python repo manipulation
> API is something that might come in handy. The footprint retrieval
> plugins can bring in a bridge into python, which in turn can grab stuff
> out of a dedicated footprint repo, over the net obviously.
Well, actually even svn has a python interface (slow as hell, I could add..)
References