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.
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
Paul's list of problems to address: 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