-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Since I do virtually all my work on a laptop, which is usually but not always connected to the Wired, I have begun experimenting with distributed SCMs. I have recently been using Mercurial for work on Wget, and then synching the work with Subversion, and am very happy with it so far. I would like to consider moving Wget development from Subversion to Mercurial at some point in the future, if it continues to work well.
For the time being, and for at least a good while, both repositories are now hosted, and will be kept synchronized. Only the _trunk_ has been converted to a Mercurial repository, and this is likely to remain the case for a while; in fact, it is likely that the rest of the Subversion repository (past release branches, bug branches, and tags) will never be converted to Mercurial, unless active development needs to happen on them. Note that, while a common idiom for working with Subversion is to create branches within the same repository for working on and later merging back into the trunk, in a distributed SCM the usual MO is to "clone" the repository, check changes into the cloned repository, and then later merge those changes back into the public, shared repository. Thus, we'll probably never have "bug branches" like we've been using (lately) in Subversion; instead, developers working on bugs will just have various repository copies holding the changes they're working on. The advantage to all of this is that we can all be working on stuff, wholly separately from the Subversion server at addictivecode.org, so that we don't need an internet connection, or for addictivecode.org to be functioning properly ( D-= ). People who aren't core developers and are just preparing patches, can still have the full functionality of being able to "save their progress" as they work, and submit their changesets back in patch form. And, it's that much easier to fork Wget in the event that I refuse to entertain a popular/necessary improvement (I'm hoping the addition of a decent plugin architecture will help avoid that sort of thing)! ;) One disadvantage I can see is that ongoing development could run the risk of becoming less transparent than I'd like. I really want to be able to see the work people are doing, as they are doing it. Regular commits to a central repository, combined with a commit notifications mailing list ([EMAIL PROTECTED]), ensure that everyone could see what everyone else was doing. Switching to a distributed SCM tool means that there's the potential for people to be doing large work on an ongoing basis, and no one gets to see it/give feedback on it until close to the end. This also has the potential for wasted work, if design flaws can be discovered only very late in the game. There is nothing I can do to prevent that, but I would encourage anyone who is doing significant work to contact me about hosting their repositories publicly, or at least host them publicly themselves and announce it to the list, so we can all keep abreast of current development work. - From this point on, development in Mercurial is preferred, but for the time being it's fine to continue working in Subversion as well. . The current development trunk on Mercurial can be browsed and/or cloned from http://hg.addictivecode.org/wget/trunk/. In the future, when I expect to be tracking multiple repositories, you'll see the list of them at http://hg.addictivecode.org/. For information about Mercurial, see http://www.selenic.com/mercurial/wiki/. Especially the download links and QuickStart page. "Pushing" (analogous to committing in a non-distributed system) is not currently supported yet. People who currently have commit access to the Subversion repository will receive information about committing to the Mercurial system separately, when support has been enabled for that. Developers who do not have commit access are encouraged to use Mercurial to work on the Wget sources, and send patches (preferably, as generated by "hg export") to [EMAIL PROTECTED] - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG8as77M8hyUobTrERCLuOAJ9xux2VuKT35XcaiIWB9XbqI4auAgCgi4AI 9IJdOp4LCMCq/VPFu9iovBk= =ynkZ -----END PGP SIGNATURE-----
