-----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-----
