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

[Aaron Griffin]

I agree with everyone else that's said it. This comes up often enough
but no one ever has a good workflow that works. I have seen nothing
proposed in this thread that is good. The ONLY thing gained is "oh
neat, it's in git". We lose quite a bit, especially in the branch-ing
department.

It seems like this is a "solution" that's looking for a problem to
happen. As far as I know, working with svn isn't a big deal and isn't
a problem.

On Sun, Mar 7, 2010 at 9:07 AM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
> * 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)

This wouldn't allow you to safely checkout multiple packages at a time
as you can only have one branch checked out at a time. Also could you
imagine scripting this to verify the version of say xorg-server that
is in extra? Ugh. With svn, it's imply a checkout of
$URL/xorg-server/extra-i686 and checking the PKGBUILD.

> * 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.

Knowing the version of the files which built a package in the repos is
important. Using tags in commit messages is a terrible idea because
not only do we need to change the PAINFULLY simple way of checking
with something using git, but we also have to parse plain text commit
messages.

> * just do normal copies and don't care about the histories.

This shouldn't ever happen. The history is important