Yes.
If you replace "SVN" with "Perforce" in your OP you've pretty much got the situation I found myself in when I started my current job, even down to the manual-change copying. Two years on we're on Mercurial and everyone agrees it's been a great change.
We have the ability to branch and merge per support case, which is unbelievably useful for QA, and the ability to create any number of throwaway branches and repositories whenever we see fit, which we can then build and verify in our CI server, then deploy to a cloud test environment and verify functionality. This has been of huge benefit in terms of peace of mind that when we do a live deploy, we're almost 100% sure that it will work (sans environment/DB issues, which are obviously out of the scope of the VCS).
Basically, what we gained from switching to mercurial is breathing space. We no longer have to worry about the cost of a branch, or the horrific merge sessions that inevitably used to follow, everything is much much easier. We also use FogBugz quite heavily so the tie-in to Kiln (their hosted mercurial) is really helpful.
The comment about the hginit site is spot on too, as an outline for a version control workflow that actually works (assuming you adjust it for your company's particular QA workflow).
The only possible flaw in moving version controls is that you will need someone who's really a driving force behind the change, who's happy to read up on the subject matter and really use the tooling to the best of its potential, which you seem to want to do.
I don't agree with the comments about team size and team distribution relating to whether to use DCVS either. Really, it's about CODE distribution. If you have multiple development cycles happening in parallel, either support cases on a legacy system, or a bunch of features or even new systems (which by the sound of it you do), you will benefit from using a DVCS.
- Cherry-pick for Mercurial is
hg graft
- History of grafted commits are easy recoverable, especially if graft performed with
--log option and without --edit+madcap editing commit-message. Also the good GUI (TortoiseHG) reveals the history of grafting.
Toy-repo with some grafting in it (release+devel branching model)
Glog ouput in console:
hg glog --style changelog
2015-08-05 Author <email>
@ * c.txt, cd.txt:
| Cnange 4
| [769d5ba1b198] [tip] <release>
|
o * c.txt:
| Cnange 3 (grafted from 3044bbf6fe3542b86d0a1a84b7455d76928b559b)
| [e58f524b1203] <release>
|
o * a.txt:
| Cnange 1
| [23d4aaf0c632] <release>
|
o * Release branch created
| [9f39dda2e0d9] <release>
|
| o * c.txt, cd.txt:
| | Cnange 4
| | [c5523fade515]
| |
| o * b.txt:
| | Edit 2
| | [7efeb998f47e]
| |
| o * a.txt:
| | Edit 1
| | [4f2e0bffed8a]
| |
| o * c.txt:
| | Cnange 3
| | [3044bbf6fe35]
| |
| o * b.txt:
| | Cnange 2
| | [278066927656]
| |
| o * a.txt:
|/ Cnange 1
| [e233699bf798]
|
o * .hgignore:
Initial structure
[3bf949e66c66]
(grafted changesets 1,3,6. Only changeset 3 grafted with --log added. Note unchanged commit-message for 1 and 6)
and this repository after all grafting in TortoiseHG
Best Answer
To answer, you have to ask yourself how you expect to use the results of these commits in the future. The most common reasons are:
The first two reasons can be served just as well with one big check-in, assuming you can create a check-in message that applies equally well to each line of changed code. If you're the only programmer, then smaller commits aren't going to make your merge any easier. If you don't plan on doing a release or testing with only part of your unsubmitted changes, then the last two reasons don't apply.
There are other reasons for making small commits, but they are for while you are in the middle of the changes, and that time is past. Those reasons are making it easier to back out a mistake or an experimental change, and making it easier to keep synced up with colleagues without huge scary merges.
From my understanding of your situation as you described it, it seems there's little to no benefit to splitting your commit at this point.