Version numbering policies can be a bit crazy at times (see Version numbers and JSR277, or Oracle, with its Oracle Database 11g Release 2: 11.2.0.1.0. See also Software Versioning is Ridiculous). But you can start by looking at the Eclipse Version Number policy as a good start. If you really think you need more than … Read more
I have tried both methods with a large commercial application. The answer to which method is better is highly dependent on your exact situation, but I will write what my overall experience has shown so far. The better method overall (in my experience): The trunk should be always stable. Here are some guidelines and benefits … Read more
WARNING: a “dummy merge”, as is recommended by @Martin_Geisler, can really mess you up, if later you want to do a true merge of the two branches. The dummy merge will be recorded, and say that you merge into the branch you did the dummy merge to — you will not see the changes. Or … Read more
Here is the method I’ve used in the past with good success: /trunk – bleeding edge. Next major release of the code. May or may not work at any given time. /branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if … Read more
From my answer to a different question: Distributed version control systems (DVCSs) solve different problems than Centralized VCSs. Comparing them is like comparing hammers and screwdrivers. Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore Good. All developers work (checkout) from that source, and then … Read more
As of version 2012.1, Perforce supports the P4IGNORE environment variable. I updated my answer to this question about ignoring directories with an explanation of how it works. Then I noticed this answer, which is now superfluous I guess. Assuming you have a client named “CLIENT”, a directory named “foo” (located at your project root), and … Read more
It’s been almost 2 years since I originally posed this question. I’d do it differently now (as I mentioned in a comment above the question above). What I’d do now would be to instead commit my changes to the one file in my local repo (you can use the hg record extension to only commit … Read more
Update: Mercurial has added –amend which should be the preferred option now. You can rollback the last commit (but only the last one) with hg rollback and then reapply it. Important: this permanently removes the latest commit (or pull). So if you’ve done a hg update that commit is no longer in your working directory … Read more
‘hg forget‘ is just shorthand for ‘hg remove -Af‘. From the ‘hg remove‘ help: …and -Af can be used to remove files from the next revision without deleting them from the working directory. Bottom line: ‘remove‘ deletes the file from your working copy on disk (unless you uses -Af) and ‘forget‘ doesn’t.