clarification on git, central repositories and commit access lists
Aaron J. Seigo
aseigo at kde.org
Wed Aug 22 18:11:21 BST 2007
On Wednesday 22 August 2007, you wrote:
> On Wednesday 22 August 2007, Aaron J. Seigo wrote:
> > unless their git trees were synced on a very frequent basis with svn and
> > unless i could commit to svn and have it sync'd back to one of their
> > trees, there's no point in me dealing with running trunk/ apps.
> You can do all of this with git-svn and what I'm suggesting. The whole
> idea is that a subgroup of people can use git and the rest of the
> developers don't even have to notice that git is being used.
ok, so going back to my earlier point which didn't really get answered before
the "you can deal with git, dude!" replies:
what would be the transition plan?
i don't care if it takes people a month to answer that question, but it would
be great if that question doesn't get lost.
i'm assuming at some point we'd move from svn to git full-scale and that's
the part that concerns me. git-svn is not good enough to keep up the "we can
use both" facade indefinitely or even for a long period of time.
moreover, i'm not sure there's a huge point to trialing git if the intention
is to keep svn forever. in fact, i'm pretty sure the goal should be to ditch
svn at some point in the future. that's the part i'm asking about.
we're already seeing issues in kdelibs with those experimenting with git-svn
accidently reverting commits made to svn, etc... a good scm system should
make that hard to do, not easier. so while i see the benefit of trialing
things so we can get the knowledge needed for both working in git (e.g.
creating HOWTOs and tutorials, finding rough edges for our work flows) as
well as for figuring out how to transition from an svn repo to a git based
set of repos from a technical POV, it makes me nervous to embark on that
without some idea of which modules will go git at which point and how.
one scenario i can see is $FOO_MODULE trying git-svn, finding themselves
annoyed at the -svn part and saying, "well, let's just go pure git". better
for the module, worse for kde as a whole.
is the plan to slowly move everyone to git-svn then remove svn at that
point? is the plan to try git-svn on a (set of) module(s), then convert that
module to git and move to the next one(s)?
and let's not kid ourselves: because of the popularity of git, i'm already
having the pleasure of dealing with git repos for bits and pieces of kde
code. best yet, those repos are not always being sync'd at all with svn.
*sigh* so when i said earlier "i won't be impressed" i probably should have
said "i'm increasingly unimpressed". this isn't a theoretical issue for me.
and really, for me this isn't a "git or not git" conversation but "how do we
manage the next scm transition". it's cool that people are thinking about
this now as well, since that probably means that by the time 4.1 is out we
can start seriously implementing this stuff as we should have a good plan in
hand. doing so before 4.1 is out (which should have a quick release cycle,
imho) would not be the wisest thing imho.
it would be nice to have at least one release cycle where we can stop
fetishizing over our tools and actually write some software, something we
haven't really be able to do for a couple of years now thanks to the various
changes (svn, cmake, qt4..). moving to git will also likely impact negatively
the productivity of that given cycle and we will innevitably lose some
contributors who can't be bothered to follow us on that transition.
all things to think about which go beyond the technical issues of using git.
 which i think, done right, could be awesome
 where "everyone" means "everyone possible", which probably translates to
less than 3/4s of people =)
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel