begin quoting [EMAIL PROTECTED] as of Fri, Jul 18, 2008 at 04:51:18PM -0700: > I'm about to embark on a large project which basically consists of > maintaining a branch of the CentOS distribution. A consulting client > modifies a few rpm's, includes a few of their own, and ships this thing on > appliances. We want to be able to keep track of exactly what went into > each machine and be able to reproduce if necessary.
Where does your organization fit into this scheme? Are you the consulting client, or is the client consulting with your organizatino? > I am going to be version controlling all of the SRPM's minus the pristine > source tarballs which never change. Start with the pristine tarballs. It helps. > They currently do something like this with FC2 and CVS but their old > process is a bit of a mess and CVS is CVS. They want to move to a better > version control system and are looking to me for guidance. > > There are only two we are considering having ruled the rest out: > Mercurial (Hg) and Subversion (svn). I take it free-as-in-beer is an important constraint? [snip] > But I don't like that > the merge handling isn't as slick due to not carrying enough meta-data > around to know about the full history and where the common parent is. > Historically I haven't done that much merging anyway but this place might > be different. I also don't like that it isn't distributed and commits > require communicating with the main repository. "Communicating with main repository" is a feature for authortative releases. You can emulate an authortative repository with Hg without much of a problem. (You can also mix-and-match; I'm using Hg with CVS at the moment: CVS is the authortative repository, and Hg is the moment-to-moment local repository that I use so I don't have compiling code more than five minutes out of version control.) > I've never used Hg before. But supposedly it is also easy to use, has > easier merging, and is distributed. I've not played with merging in Hg (I got very good with merging in CVS and fairly good in perforce) at all, but it doesn't do a bad job of being a drop-in replacement for CVS. Maybe not so transparent as SVN, but the normal workflow (update, add, commit, diff, etc.) can work just the same. > I don't so much like the fact that it > doesn't seem to implement something as simple as keywords (So I can't put > $Version:$ in the /etc/motd and know what the version of this distro is), Even the CVS folks recommended against using $Revision$ as a product identifier; embedded keywords are for reconstructing source from binaries. For product-level version-control, you should have a "version" file that your release process updates, commits, and embeds into your product. > doesn't do webdav, and you can only check out a whole repository. Not just > an individual file or directory. The latter point has interesting > implications for my preference to version control system files. Would I > need to create a separate Hg repo for each host or each directory on each > host or something equally silly? With svn I have a Not so silly, just move the "repository" one level down. > /hosts/hostname/etc/ for example and I can do: > > # cd /etc/ > # svn mkdir host://svn.mydomain.com/hosts/hostname/etc > # svn co host://svn.mydomain.com/hosts/hostname/etc/ . > # svn add sudoers > # svn commit > > And now my sudoers file is version controlled. I'm not sure how I will do > this with Hg. cd /etc hg init scp [EMAIL PROTECTED]:/repo/default.hgignore .hgignore hg add sudoers hg commit sudoers ssh [EMAIL PROTECTED] mkdir /repo/hosts/hostname cd /repo/hosts/hostname hg clone ssh://[EMAIL PROTECTED]:/etc (or something like that. I haven't used the ssh: stuff yet, and I suspect you can push instead of clone/pull. All of the above is mere handwaving... so far I transport hg repositories via sneakernet) The point being that you can structure your "repository" so that all the "clones" are sibling HG repositories. (Hm, I should futz with this a bit.) > One might suggest I use svn for host configs and Hg for larger coding > projects which are more likely to be distributed anyway but using and > administering two different tools for almost the same thing bugs me. The one problem I've had with hg is that python on Solaris is...flaky. (This can be mitigated by installing one's own Python.) But then, SVN is worse, what with the immense dependency chain. I doubt you're going to do much on a solaris either way. > I'm still doing research on these issues and I'll let you know what I > decide. Keep your pro/con notes so you can give us the chain of reasoning for your decsion. -- Why can't I have a perl version of Hg? Stewart Stremler -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
