Hi all,
I will be implementing a version control system in C++ for my final year project.
I would like to know:
Thanx a ton,
You can't create a full version control system as your final year project. And in C++, it's close to impossible in a 4-6 Month timeframe even for a full team. ( I think FYPs normally have a 4-6 month timeframe).
What you should be aiming at is creating a subset of a good version control system. Look at SVN for a start and try developing a subset of it. e.g., SVN MINUS Branching Support should be way more than enough.
And Why C++? Try doing it in some other language which has a better support of libraries e.g., C#. Remember, C# applications ship quicker :)
If you want to do something different / innovative, then I'd reccommended looking into targeting your revision control at something other than source code. There are other application where revision control could be useful (e.g. revision control for documents) and source control has been extensively done already - your unlikely to cone up with an innovation that doesn't already exist in some other source control already.
I admire your ambition, your course may be different from mine, but you tend to get more marks for your report rather than the code, so it's important to know what you can archive given that writing the report will take 2,3 times the time for coding.
You probably need to try to implement a few other ideas extremely roughly to give yourself an idea of the difficulty of each one before you commit.
Linus Torvalds may well have developed the core of git in four weeks, but it took many others a lot longer to make it really usable, and he is Linus Torvalds!
Ignore the people who say it cannot be done. In their seminal book "The Unix Programming Environment" Kernighan and Pike develop (a very basic) one using shell scripts, diff and sed in a very few lines of code. I'm sure you can do something similar.
One thing many miss is the ability to shelve changes - ie check files in as a temporary commit, so you can save your working copy regularly (eg every night in case your computer gets stolen/broken) but without these 'in-progress' changes showing up in the main list of changes. When you've finished working on them, you then check them in to commit them as normal and the temporaries are removed (as you don;t want to fill your VCS with irrelevant versions).
Another thing many fail to do is automatically notify the user of changes. eg. svn you have to run svn update to get any changes made by team members, it'd be nice to have that automated so changes were retrieved on every operation (eg. save a list of changes since and send a highly optimised data block to the client after every result)
Try a better way of storing binary files, most SCMs are designed to handle text, and work on binaries only by chance (and not very well usually).
In many ways I'd suggest starting with an existing open source SCM and extending it with your changes. That way, you do get the benefit of the basics for free leaving you to concentrate on the fancy features but at a cost of learning how to develop that SCM. Subversion, git, mercurial, bazaar are all good reference SCMs.
The number one feature should be:
MERGING
If you wrote a complete VCS and your merging sucks, you will not use that feature. And your VCS is now simply a glorified backup-system.
Merging is also probably the most difficult part to implement.
The ability to search an entire codebase for instances of a chunk of text. This gets really important as the codebase gets older (or as new people join a project and are learning the codebase). SourceSafe has it but some others don't. Yes, Sourcegear Vault, I'm looking at you.
Granted, it's one of the few things that SourceSafe does right, but it needs mentioning.
Stand on the shoulders of giants. What about contributing to an existing version control system, adding new features and/or fixing bugs better than reinventing the wheel?
Depending on the language you prefer, you will probably find a good open source written with that language.
Python > Mercurial, C > Git, C++ > Monotone
Take a look at article by Tom Preston-Werner, cofounder of GitHub: The Git Parable, describing how a Git-like system could be built from first principles. Worth reading.
Try also to avoid traps other fell in, for example design file formats and network protocols with extendability in mind, to not have to hack it if the format changes; either provide version number or a list of capabilities. But that is more advanced thing, and it assumes that you want for this VCS to go beyond term project.