Using a VCS

[roberts]

I'm trying to add a RCS/VCS to my programming and decided to at least try Mercurial. I can get Git later if I find Mercurial isn't doing what I need, but I think it will.

I have questions on organizing repositories since this it has been perhaps a couple decades since I programmed and thus used a RCS (CVS was the one I used back in the 80s and early 90s).

Should each project get its own individual directory for its repository or should they share the same repository directory?

I did a bit of googling and found this bit of advice:

http://stackoverflow.com/questions/222827/how-do-you-organize-your-version-control-repository

Can any one concur and help me understand the finer details as I need to know later on?

[1yR4jE8b]

With centralized version control systems (cvs, svn, perforce, etc...) it is common to put everything into one monolithic repository because you can checkout whatever you need and leave everything else on the server. With distributed version control systems (git, hg, bzr) you generally clone the entire project history, so having one monolithic repository will bring in lots of things that aren't required for a specific project, will use substantially more disk space, take longer to download, and the project history will be cluttered with unrelated commits.

When I use start a new project, I create a new repository for it. The overhead of having multiple repositories is moot, and actually makes sharing code with people much much easier. If I want to reuse some code that I"ve used in a previous project, I use a subrepository. Mercurial is awesome (and does everything git does, usually in a much simpler way). It has a much more polished UI and for 99% of cases, just as fast.

[roberts]

Ty Darkest, that helps a lot.

I'm using VC++ 10 express and currently committing .cpp, .h, .vcxproj, .vcxproj.filters and .vcxproj.user to the repository. Is there any other files I should consider committing?

[1yR4jE8b]

Instead, you should be considering what files you *shouldn't* be commiting. I tend to put any directory that has build content in the .hgignore filter (such as ipch/ bin/ obj/ Debug/ Release/), because the IDE will generate those automatically when you compile. Visual Studio also uses some rather perculiar files that it generates automatically, such as .suo and .sdf files that are better off ignored. As a rule of thumb, I ignore any binary files other than resources required for the application.

I prefer to not include .user files because they are user-specific settings. I don't necessarily want to propagate my settings to other people when they clone/pull from me.

Knowing how the .hgignore file works is essential reading: http://www.selenic.com/mercurial/hgignore.5.html

[roberts]

Is there a way to delete a committed file? lol. I can't seem to figure out how to remove the user file from the repository.

Nevermind, I thought TortoiseHg would automatically update the view but I had to refresh. I rolledback and will redo this.

[1yR4jE8b]

You can use `hg delete` or `hg forget`, but it only removes that file from that point on (not from the history), not usually a problem unless you can accidentally commit something that has a password or something.

[roberts]

Darkest, I made some revisions and tested. What I have now, I want to save. The overall code remains the same, but there were some fixes to bugs and FP issues.

I guess my question is, does this qualify as a .0x revision and how do I commit with a revision note? The help system kind of doesn't cover the finer details and I don't want to risk wiping out the history, if that is possible.

I plan to add functionality and try to improve performance later on, so this little util is going to go under the knife quite often.

[1yR4jE8b]

You simply use the `hg commit` command, an editor should pop up and you can write a message describing the changes that you have made.