[arch-general] svn packaging, abs => git ?

[Ray Rashif]

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