On 07/03/2010, Dieter Plaetinck <dieter@xxxxxxxxxxxx> wrote: > On Sun, 07 Mar 2010 14:49:01 +0100 > Thomas Bächler <thomas@xxxxxxxxxxxxx> 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
