Re: Version tracking in Wget binaries
Micah Cowan [EMAIL PROTECTED] writes: Make my src changes, create a changeset... And then I'm lost... Alright, so you can make your changes, and issue an hg diff, and you've basically got what you used to do with svn. That is not quite true, because with svn you could also do svn commit to upload your changes on the global repository seen by everyone. It is my understanding that with the distributed VC's, the moral equivalent of svn commit is only to be done by the maintainer, by pulling (cherry-picking) the patches of various contributors. To me that sounds: a) horribly error-prone if the maintainer doesn't have access to firewalled checkouts of various contributors (patches can and do misapply), and b) actually *more* centralized than CVS/svn! It is most likely the case that I simply didn't (yet) get the DVCS way of doing things.
Re: Version tracking in Wget binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Make my src changes, create a changeset... And then I'm lost... Alright, so you can make your changes, and issue an hg diff, and you've basically got what you used to do with svn. That is not quite true, because with svn you could also do svn commit to upload your changes on the global repository seen by everyone. It is my understanding that with the distributed VC's, the moral equivalent of svn commit is only to be done by the maintainer, by pulling (cherry-picking) the patches of various contributors. Untrue. That is simply the model some (notably, Linus and friends) choose to use. As with the Subversion set up, active developers with permissions may push to the central repositories; I actually mentioned this during the initial announcement, but am using SSH key-based authentication to accomplish this, and so require people's SSH keys in order to give them push access. So far, the only one who has given their SSH key is actually Ralf Wildenues, whose key I requested so he could easily push any necessary changes related to the Automake stuff. So: send your key, and you'll have push access! Note that I still prefer to review non-trivial changes, just as I did in Subversion; but just as in Subversion, I decided against ACLs and allowed everyone write permission to trunk, though I preferred to merge there myself, I want all core devs to have write permission to the public repos, so they can push quick fixes. It is most likely the case that I simply didn't (yet) get the DVCS way of doing things. It takes a little bit of getting used to, but you'll find that many things directly translate from using a non-distributed SCM. The biggest differences that arise (for me so far) tend to be related to the fact that history is not a linear series of events, where each log entry is the child of another; it is instead a directed acyclical graph, where the history can branch off and re-merge later, leaving all history intact. Subversion and friends, of course, support branching and merging, but the history wouldn't merge along with the changes, and you'd typically get the branch merge as one big slurp of the total changes. Tools like svnmerge helped address this (by merging each change individually, which could be problematic in some circumstances). For my part, I found using Mercurial very easy to learn, and it is purposely designed to use an interface very similar to Subversion. It just takes a little getting used to, like any conversion to a new, heavily-relied-upon development tool. - -- 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 iD8DBQFHE3177M8hyUobTrERCMpZAJ9MUGXaYa2r+SBmFEujdrnwvjNITQCfevJN qh2Jicj1A9Iv8Po3E8EUGTA= =gkeP -END PGP SIGNATURE-
RE: Version tracking in Wget binaries
OK, so I'm trying to be open minded and deal with yet another version control system. I've cloned the repository and built my mainline. I do not autogenerate a version.c file in windows. Build fails missing version.obj. Note that in the windows world, we use Nmake from the MSVC install - no GNU tools required. An aside on Hg... Confirm for me that I basically need to do the following: Create a clone repository: hg clone http://hg.addictivecode.org/wget/mainline Get any changes from mainline into my clone hg pull http://hg.addictivecode.org/wget/mainline Make my src changes, create a changeset... And then I'm lost... And as a follow-up question - what does Hg get you above and beyond CVS or SVN? I kind of get the non-centralized aspect of repositories and clones, but I don't understand how changesets and tips work. My thoughts are that there is *one* source of the code (with histories) regardless of SVN, Hg or whatever. Hg's concept of multiple clones and repositories is quite interesting, but doesn't feel right for the remote, non-connected group of developers that wget gathers input from. If we were all behind a firewall or could share out each user's repository, it might make more sense, but I (for one) wouldn't be able to share my repository (NAT'd, firewalled, corporate desktop), so I just don't get it. Chris Christopher G. Lewis http://www.ChristopherLewis.com -Original Message- From: Micah Cowan [mailto:[EMAIL PROTECTED] Sent: Saturday, October 13, 2007 4:59 AM To: Wget Subject: Re: Version tracking in Wget binaries -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Among other things, version.c is now generated rather than parsed. Every time make all is run, which also means that make all will always relink the wget binary, even if there haven't been any changes. I personally find that quite annoying. :-( I hope there's a very good reason for introducing that particular behavior. Well, making version.c a generated file is necessary to get the most-recent revision for the working directory. I'd like to avoid it, obviously, but am not sure how without making version.c dependent on every source file. But maybe that's the appropriate fix. It shouldn't be too difficult to arrange; probably just version.c: $(wget_SOURCES) or similar. version.c is no longer unconditionally generated. The secondary file, hg-id, which is generated to contain the revision id (and is used to avoid using GNU's $(shell ...) extension, which autoreconf complains about), depends on $(wget_SOURCES), and $(LDADD) (so that it properly includes conditionally-used sources such as http-ntlm.c or gen-md5.c when applicable). This has the advantage that every make does not result in regenerating version.c, recompiling version.c and relinking wget. It has the potential disadvantage that, since $(wget_SOURCES) includes version.c itself, there is the circular dependency: version.c - hg-id - version.c. GNU Make is smart enough to catch that and throw that dependency out. - -- 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 iD8DBQFHEJb07M8hyUobTrERCE4rAJ9gKXonGN9bRydErVkxtZF8g723CACeLbhD VYUyd0MnjBdjcRXMSTge0ZE= =cC2V -END PGP SIGNATURE-
Re: Version tracking in Wget binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher G. Lewis wrote: OK, so I'm trying to be open minded and deal with yet another version control system. I've cloned the repository and built my mainline. I do not autogenerate a version.c file in windows. Build fails missing version.obj. Right; I think I mentioned that would happen. Note that in the windows world, we use Nmake from the MSVC install - no GNU tools required. Right; and I don't expect that you'll be able to do it exactly as I've done. However, the contents of src/Makefile.am should give good hints about how it could be done in Nmake. AFAIK, the only thing Unix-specific about the rules as I've done them, in fact, is the use of the Unix cut command. If absolutely necessary, that part could be removed, with the Nmake rules similar to: hg-id: $(OBJS) -hg id $@ It's just that only the first word is needed. An aside on Hg... Confirm for me that I basically need to do the following: Create a clone repository: hg clone http://hg.addictivecode.org/wget/mainline Approximate equivalent to svn co. Get any changes from mainline into my clone hg pull http://hg.addictivecode.org/wget/mainline Equivalent to svn up. Make my src changes, create a changeset... And then I'm lost... Alright, so you can make your changes, and issue an hg diff, and you've basically got what you used to do with svn. Or, if they're larger changes, you can run hg ci periodically as you change, to save progress so to speak. And as a follow-up question - what does Hg get you above and beyond CVS or SVN? I kind of get the non-centralized aspect of repositories and clones, but I don't understand how changesets and tips work. Well, changesets are in all SCMs, as far as I know. A changeset is just the set-of-changes that you check in when you do svn ci or hg ci. Every revision id corresponds to and identifies a changeset. tip is just the Mercurial equivalent of Subversion's HEAD. In Mercurial, the tip is always the very last revision made, whereas heads are the last revision made to each unclosed branch in a repository. My thoughts are that there is *one* source of the code (with histories) regardless of SVN, Hg or whatever. One official one, sure. For me, the major advantages are that I can be working on several things, each with history, without touching the official repository. I can work on large changes while I'm in my car while my wife drives the family out-of-town, without having to worry about screwing something up that I can't back up to a good point (other than back to the last official point in the repo, or whatever I had the foresight to cp - -r). And, I can check in changes where each time it takes a hair of a second, and then push it all over the net when I'm ready for it to be sent, instead of taking several seconds for each commit. Believe me, you begin to appreciate that after a few times. Admittedly, these advantages are mainly advantages to pretty active developers, which, at the moment, is pretty much just me. :) I've definitely found use of a DVCS to be absolutely awesome for my purposes. Hg's concept of multiple clones and repositories is quite interesting, but doesn't feel right for the remote, non-connected group of developers that wget gathers input from. If we were all behind a firewall or could share out each user's repository, it might make more sense, but I (for one) wouldn't be able to share my repository (NAT'd, firewalled, corporate desktop), so I just don't get it. Sharing is a potentially useful aspect of DVCSses, to be sure, but it's not all it's got going for it, and in fact isn't really the reason I made the move. - -- 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 iD8DBQFHEugL7M8hyUobTrERCCM/AJ47cwY0rm0FBsEKH6PhKLwFiyTrxgCfasIY GJiUAR8s7rX09O2F9ZIt4uQ= =COwb -END PGP SIGNATURE-
Re: Version tracking in Wget binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Micah Cowan wrote: Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Among other things, version.c is now generated rather than parsed. Every time make all is run, which also means that make all will always relink the wget binary, even if there haven't been any changes. I personally find that quite annoying. :-( I hope there's a very good reason for introducing that particular behavior. Well, making version.c a generated file is necessary to get the most-recent revision for the working directory. I'd like to avoid it, obviously, but am not sure how without making version.c dependent on every source file. But maybe that's the appropriate fix. It shouldn't be too difficult to arrange; probably just version.c: $(wget_SOURCES) or similar. version.c is no longer unconditionally generated. The secondary file, hg-id, which is generated to contain the revision id (and is used to avoid using GNU's $(shell ...) extension, which autoreconf complains about), depends on $(wget_SOURCES), and $(LDADD) (so that it properly includes conditionally-used sources such as http-ntlm.c or gen-md5.c when applicable). This has the advantage that every make does not result in regenerating version.c, recompiling version.c and relinking wget. It has the potential disadvantage that, since $(wget_SOURCES) includes version.c itself, there is the circular dependency: version.c - hg-id - version.c. GNU Make is smart enough to catch that and throw that dependency out. - -- 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 iD8DBQFHEJb07M8hyUobTrERCE4rAJ9gKXonGN9bRydErVkxtZF8g723CACeLbhD VYUyd0MnjBdjcRXMSTge0ZE= =cC2V -END PGP SIGNATURE-
Re: Version tracking in Wget binaries
Micah Cowan [EMAIL PROTECTED] writes: Among other things, version.c is now generated rather than parsed. Every time make all is run, which also means that make all will always relink the wget binary, even if there haven't been any changes. I personally find that quite annoying. :-( I hope there's a very good reason for introducing that particular behavior. BTW does that mean that, for example, running `make install', also attempts to relink Wget?
Re: Version tracking in Wget binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Among other things, version.c is now generated rather than parsed. Every time make all is run, which also means that make all will always relink the wget binary, even if there haven't been any changes. I personally find that quite annoying. :-( I hope there's a very good reason for introducing that particular behavior. Well, making version.c a generated file is necessary to get the most-recent revision for the working directory. I'd like to avoid it, obviously, but am not sure how without making version.c dependent on every source file. But maybe that's the appropriate fix. It shouldn't be too difficult to arrange; probably just version.c: $(wget_SOURCES) or similar. It's not 100% effective; it relies on (1) this source directory being managed as a repository, and (2) the user possessing a copy of Mercurial (which seems likely if (1) is true). So, for instance, clicking the bz2 link at http://hg.addictivecode.org/wget/mainline means you aren't getting a repository, and won't get the revision stamp. :\ I'm currently looking into ways to deal with this. For instance, I can add an extension to the repository on the server that ensures that archives are modified to include their version information before they're shipped out; that could help. There is also the problem that, if it _is_ a repository clone, the local user may have made local changes and committed them, in which case I'll get a different revision id (which is a truncated SHA1 hash, and not a linear number as with Subversion*), with no information about how it relates to revision ids I know about from the official repos. * Mercurial actually has linear numbers, but they're only meaningful to that one specific repository instance, as the same hashes may have different corresponding numbers on someone elses clone. They're basically for making the local repo easier to work with, not for sharing around. I'm happy to field suggestions! BTW does that mean that, for example, running `make install', also attempts to relink Wget? Yup. - -- 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 iD8DBQFHD5lY7M8hyUobTrERCDDsAJ9m4u7suve+sqID92ebcrq1VvrhawCgi+T4 nunTe5ve/E96fmi4EB7OYbI= =ykJF -END PGP SIGNATURE-
