Re: svn packaging, abs => git ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux