On 07/03/2010, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sun, 07 Mar 2010 14:49:01 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
1) We want to be able to see which PKGBUILD matches the package in the repository. In SVN, we use copy - which is subversion's equivalent to branching: By copying, you create a reference and all history of the copied file is still there. In git, copying means that the copy has no history, it is entirely unrelated to the original. The only equivalent in git would be branching - but you cannot branch a single file or path, you can only branch the entire tree.
Note that with "package in repository" Thomas means the <package>/repos/i686 and such directories in svn.
There are some approaches we could take: * git diff has a -C flag to detect copies. --find-copies-harder For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command inspect unmodified files as candidates for the source of copy. This is a very expensive operation for large projects, so use it with caution. Giving more than one -C option has the same effect.
so, we tell all packagers to do the add/update/test/add-to-repositories in one commit. (or use the slow -C flag, I don't know how often you want to do this)
* git branches. 3 branches or so for each package. that's a lot of branches, but maybe that's not really a problem, depends on how many times you want to merge branches i guess (i.e. how related packages are to each other)
* we could also get rid of these branch directories. what's the point of them anyway? the tools who build the packages (tarballs) must know the latest version for the particular architecture? maybe we can put tags in the commit messages, or keep a textfile in the package directory to know which "state" of the directory is usuable to build packages for.
* just do normal copies and don't care about the histories.
I'm not really a packager so I don't know how feasible all approaches are, but some of them seem pretty feasible.
2) Partial checkouts and commits: We check out single directories and most importantly we commit to single directories without updating the rest of the repository. These operations come naturally to SVN, but they are against the very concept of git.
did you see http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7 ? is this not enough? I mean, you can clone the (complete) repository, checkout the git repo sparsely, commit in your subdirs, add the clone as remote in your original and pull in the changes. okay you do have the complete 57MB repository locally, but at least a clean checkout. I actually just tried this and it just works!
It will work, no doubt. But the problem is this: svn co $url --depth empty # nothing cd $dir svn up $pkg ..against this: git clone $url # everything cd $dir git config core.sparsecheckout true echo $pkg > .git/info/sparse-checkout git read-tree -m -u HEAD And then with svn you can maintain the sparseness with 'svn up --set-depth empty' everytime. And also I think the main thing here is git will work backwards, and as such, will pull in the whole repo: "DO NOT CHECK OUT THE ENTIRE SVN REPO." From: http://www.archlinux.org/svn/ So when someone says it's alright to do that, then I think it'll not be too hard to migrate the tools to git, and use those tools instead of using git directly. In this case, I think we'd no longer need 'archrelease' since a git commit is local only, and use push instead to "release" the package. That'd then eliminate all directories except for the package itself. -- GPG/PGP ID: B42DDCAD