[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]

[Jason Chu]

I'd just like to start by saying this is the best git suggestion I've seen
so far ;)  Well done.

> And now for part 2 of 2 of my email. This one may be a bit long so
> hold on to your hats and try to stay with me.
> 
> Links:
> Gitweb: http://www.archlinux.org/~dan/newrepo/gitweb.cgi?p=repo.git;a=summary
> Download bare repo: http://www.archlinux.org/~dan/newrepo/repo.git.tar.gz
> Clone repo address: http://www.archlinux.org/~dan/newrepo/repo.git
> 
> First off, I'm going to step through the examples in the repository,
> which is much easier to visualize if you have a local clone and are
> using a gitk or qgit-type tool where you can see the branches and
> merges.

<snip>

I like how the package repositories are separate from the version control
repository.  Like you say later, it makes it really easy to move packages
from one repo to another.

And it helps to treat package repositories as branches... though... how do
you know what PKGBUILD to use for a repository other than core/extra?
There's a test_kernel24, test_kernel, and test_udev.  Each of them have
different versions of kernel24, kernel, and udev.

In the svn suggestion, we're explicit about which version is in testing,
how would we figure it out in git?

If all commits dealt with only one PKGBUILD, I could see this being figured
out, but if you have multiple changes in a commit, they could conflict.
What then?

I can't really find a good place to put all these comments, so they're just
going at the top here...

I could see a problem with possibly using branches *and* version control
repositories to both represent package repositories.  Things could get
lost.

> Wow, sorry about that overload there.
> 
> Paul's list of problems to address:
> > a) Moving packages from one repo to another is hard.
> In this case, the definition of a repository will be outside of the
> actual PKGBUILD tree. Similar to Jason's flat-tree layout, the actual
> pushing of packages into repos wouldn't be determined by where the
> package files live, but by an external configuration. Thus all you
> would need to move a package is modify the config.
> 
> > b) Placing packages in multiple repos is hard.
> I'm going to interpret this as the current/testing idea. With this
> system, placing a package in testing should be as easy as making the
> changes on a 'test_' topic branch.
> 
> > c) Continued separate-track development on a package while in
> > testing is hard.
> Addressed above.
> 
> > d) Tracking multiple binary repos for different architectures is hard.
> This is something that needs to be addressed, and I do need to figure
> it out. The issue can be generalized more- how do we track what is
> actually released vs. what is in the repository? (A split CURRENT &
> HEAD tag scenario comes to mind from current CVS repositories) With
> GIT, we surely have the tools that can solve this issue but it needs
> some further thinking.

Yeah, you'd almost want to have a "release" repo and a "development" repo.
Any patches that go into the "release" repo are actually in the
package repositories and "development" is just the staging area for
changes.

To track separate longterm repositories, you could have multiple branches.
You just have to be sure to not lose commits in other branches.

> > e) Maintenance of a package by more than one person is hard.
> Developers on this system can dive right into the full GIT toolset and
> leverage it to do what they need to do. If two people are working on a
> rebuild, they could easily push and pull trees between each other
> before making the final commit to the main repository. In additon, GIT
> merges rather than overwrites by default so it is hard to stomp on
> changes by other developers.
> 
> Things that need to be done:
> 1. Write a toolkit. Not looking for anything huge or crazy here (just
> take a look at Jason's SVN-based tools), but usage of this system by a
> developer should be easy. Typing one command instead of having to
> string together multiple GIT commands is a plus, and allows for more
> uniform procedure-following by all devs.
> 2. Examine feasibility of automated DB scripts. I think if things like
> the 'test_' prefix are done, we can automate db building when a master
> repository is pushed to. However, I don't know this for sure, and it
> would be wise to check on what would happen with edge cases and such.
> 3. Figure out best way to track binary repos and changes that haven't
> yet been pushed to a built package.
> 
> Please comment on anything and everything above and I'll respond. And
> as I said in my first email tonight- so far Jason's SVN solution is
> the only other one that looks good (besides hopefully this one). Let's
> keep the ball rolling here.

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071029/2cbf1e41/attachment.pgp>