Moving incomplete code between mercurial checkouts

I checked out the codebase on my desktop comput开发者_开发知识库er and worked some on it. Now Im going away and want those changes on my laptop.

One solution is to simply commit the incomplete code and then pull them on my laptop. But that would then mean that I have uncompiling code in the repos, something I would like to avoid.

Whats the best way to handle this? Generate and apply a patch? Using hg serve to move the incomplete change?

---

Here are three ways to do this. I'll discuss the pros and cons of each:

Option 1: use hg diff to get a diff file showing the uncommited changes, and then hg import --nocommit on the receiving end to apply those changes without creating a new changeset

• Pros: simple, creates no changesets
• Cons: doesn't actually use mercurial ike the DVCS it is. Might not catch newly added files

Option 2: Commit on the sending side, push to the receiving end (or pull from it, or put a hg bundle on a flash drive), bypassing the work server, update on the receiving side, and then hg rollback on both sides to eliminate the changeset (but leave the changes.

• Pros: Using push and pull to move over changes like mercurial intends
• Cons: Hacky. Relies on rollback which only works 1-level deep. Accidentally pull twice and you can't undo the first.

Option 3: Commit on the sending side. Push to a developer-repo that only you access, and Pull on the receiving end. Don't push to the company repo until things build, but when you do push push all the interstitial changesets

• Pros: Exactly what a DVCS is about. Your order of work is documented and preserved
• Cons: requires setting up a you-only clone

FWIW, I recommend option 3. Per-developer repositories are exactly what DVCSs are about. If your company doesn't make it easy to set one up on a server you can access from home and away, point out to them the immense value in having documented the process that got a developer to a completed fix/feature and that encouraging developers to push to a not-required-to-compile repo frequently is good for daily backups.

Lastly, after you're done with your feature or fix you can always collapse-away all the intermediary changesets. I don't like do it (I'm a show your work kind of guy), but here's how: Can I squash commits in Mercurial?

---

Hmm.... if you want the "head" to be clean then (and I may not get the terms right for Hg, I think in SVN, not done enough Hg yet):

Branch before your current round of changes, setting the you current work i.e. the stuff that doesn't build to be on the branch, commit the changes to the branch, pull the branch to the laptop, go, play, come back, then merge it all back together (which should be fairly trivial as the head won't have changed) and excise the branch if you really want to!

I've seen variations on this written up "in passing" several times - always held up as the reason why DVCS is "better" though it would probably take me the rest of the day to find you an example )-:

Alternatively (thinking a bit more - and allowing that I use SVN much more) - the key would be that I could commit to my local "WIP" repository all I want, broken code or not and therefore would pull (or push) my current WIP to the laptop and back safely. The repository that needs to be clean (to always build) is the "server" one so whilst I may commit locally I wouldn't PUSH to that repository - the server one - until its all good... (that "server" repository would then be the one that triggers the build server and so on). I suspect this latter is closer to most of the examples I've seen described.

---

Another cool option (but a little bit more involved) is to put the unfinished changes into an MQ (enable the mq extension first) and version the mq (qinit -c). Then, use qcommit to commit the current state of the patch queue and sync your unfinished work by pulling and pushing the mq.

---

It might be seen as uncultured, but I often use rsync to move "in-progress" repositories around over SSH until I get to a point where there is something worth committing.