On Wed, Aug 24, 2011 at 3:53 PM, Florian Pritz <bluewind@xinu.at> wrote:
So it came up in IRC again and I'll try to sum up the discussion:
Great. Another bitchfest on this topic! I'm going to get a bit pissy here because it isn't like git wasn't around when we moved to SVN, and we came to the conclusion then that the workflow with git was no better/worse than the one proposed by Jason Chu using SVN. Obviously git has changed since then (as has SVN), but we're putting the cart ahead of the horse here- our (well, not mine) insistence on using git to manage packages, rather than actually listing the damn problems we have now in an objective manner.
SVN checkouts tend to break,
some people only use it for our repos and not anywhere else, it's slow. Don't disagree with you on this point, however your amazing git 'one repo per package' idea below sounds like a nightmare for those of us
Examples? Or is this just hearsay like everything else because we're on a witchhunt, and SVN looks like one. I've had a full repo checkout for 2 years that has never broken. Ever. that like having full checkouts and updating them regularly. Submodules or not, its going to be disastrous.
We agreed on one git repo per package because you can't do partial checkouts in git and you hardly need the history of all packages anyway. Oh really? I tend to like having full history and a timeline, especially when I can link it to a move from [testing] to [core] of 60 other packages. So we're throwing any sort of atomicity and ordering away?
You also realize that the full git history of current SVN weighs in at only 120 MB? This isn't all that bad, and at least there we have a bloodline of all packaging activity rather than having that scattered across 4339 git repositories.
To keep track of released packages, dbscripts maintains it's own (git?) meta database which contains only the package version and pacman repo of the package. The version corresponds to a tag in the package's git repo.
We can't use tags like "testing-i686" because you can't reuse tags in git. So how do we know what version is in testing vs what version is in core vs trunk/master? Branches?
I'd like to hear some comments about this. My comments are this- last time I proposed a git solution[1] (yes, I did this back in 2007!) I at least made a sample repo and demo of it, which let people weigh it against the SVN option also on the table at the time. I'm not happy with change just to change, and this current "let's move to git" plan sounds half-baked, and not all repercussions thought out.
Like I said, sorry for being pissy about this. I'm glad the new blood here is trying to push change for the better, but I'm worried you are just pushing change fore the sake of change, given that we've spent time researching and developing our switch from CVS and chose SVN over git at the time. Here is the former discussion lead email: http://mailman.archlinux.org/pipermail/arch-dev-public/2007-October/001904.h... And see the October 2007 archive, search "Killing CVS", for many more: http://mailman.archlinux.org/pipermail/arch-dev-public/2007-October/thread.h... -Dan [1] http://mailman.archlinux.org/pipermail/arch-dev-public/2007-October/002191.h...