Toshio Kuratomi wrote:
Doug Ledford wrote:You're straying into git specifics here. Different upstream SCMs will give us different abilities.This is where I point out that Jesse's email I responded to about the upstream RPM devel cluttering up fedora's devel branch, the one where I said he wasn't imaginative at all in terms of branching, is a perfect example. Panu mentioned he was pulling the new rpm from the upstream git repo. We would simply clone that. In the process, our official repo would have a list of references to the remote, upstream repo's branches. These branches are inviolate by us. We can never change them, they simply are a copy of upstream's metadata. We can, however, create our own branches. In fact, the standard modus operandi in a case like this would be to clone upstream, then create tracking branches in our repo that show us upstreams branches (because we don't see anything but master from upstream by default), then create our own branches (so upstream has it's own devel branch, usually just named master, and we could create our own branch named fedora-devel that would be our primary devel branch, then as we approach a release we can branch from fedora-devel to f-8, f-9, etc), and then we simply merge or don't merge from upstream to our devel branch as we see fit. For things where we want to follow upstream, we can actually configure fedora-devel to automatically merge any new changes from upstream's master branch in anytime we do a pull (in fact, you can do this on a per branch basis, any given branch can be told to automatically merge changes from another branch into it, or it can be a more static branch that doesn't auto merge anything). Had this been the case, then merely setting the fedora-devel branch to not automerge from the remote (upstream) devel branch would have resulted in all of the auto-rebuilds and things like that working just fine on the fedora-devel branch as Jesse mentioned needed to happen, but it would have let us see the changes going on in the remote tracking branches and everyone who bothered to update their rpm repo would see those changes on those remote branches and know something was up.
There are two categories; Distributed and non-distributed. The most important part is that which lets you uniquely identify one particular commit uniquely. git, hg, bzr and pretty much all the more-than-hardly-used-at-all DSCM's use SHA1 or something similar to identify a particular commit and also the history leading up to it. The fact that hg and bzr try to hide them while git does not doesn't mean they don't exist. For non-distributed SCM's (svn, cvs) I'd recommend any of the following: * importing them to whatever dscm happens to be easiest to do all the fancy stuff people want to do * importing tarballs to the dscm that would have been used above * keep using tarballs and patch-files
We'll need to figure out what things, like this, are important to us,
In order of priority:
1. Ability to name one specific commit uniquely
2. Ability to generate tarballs from said commit
3. Easy and cheap branching
Only the first two are vital. The third one is for developer convenience
and disk-space saving.
Assuming 2 works properly, you don't never need to change anything in
RPM for this to work. At my day-job, we let our horde of git repositories
schedule builds whenever something is pushed to one of three different
branches (master, maint, next). It does this by generating a tarball
named by the "git describe" output and some very simple sed-hackery.
When a signed tag is pushed to a repository the build result is also
sent to our beta-release repos.
The only pre-processing we do post-checkout is to sed out the version
and release fields with parts of the "git describe" output.
In the spec-file's %build section, we do
sed -i -e "s/##FULL_VERSION##/%{version}-%{release}/" \
version.{h,php,pl,py,sh,lua,whatever}
so we never need to have any "preparing for release blah blah" commits
cluttering the repository and no package will ever have faulty version
numbers.
I'd be happy to share our stuff. Although it's got quite a lot of stuff
hardcoded into it (paths, server addresses etc) someone interested could
perhaps get some mileage out of looking at them.
--
Andreas Ericsson andreas ericsson op5 se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231