I'm working on what I call "semantic version control". Namely, instead of diffing and merging text, the goal is to parse the program and diff/merge the AST. EDIT: A better way to state the goal: I want to take advantage of the underlying structure of a computer program to inform the diff/merge. The first step just happens to be diffing ASTs, but I go beyond this. I already have some neat features--for example, I can…
I was just wondering what would be the use cases of this. I mean to say code version control really is text version control. The whole idea is to track the changes, the cause for the change and who changed with some history. Added with this ability to do other code release related changes like revert, merge etc. What is the use of semantic version control?
I don't have any features beyond that right now--it does not actually manage different versions itself right now. Once I have the client finished, you will be able to use it along with a normal VCS like Git.
However, there are certain advantages to using an approach like this to manage commits as well as diffs and merges. For example, given the information I'm gathering, you would be able to automatically mark commits that only changed comments but not actual code. Additionally, you would be able to perform some fairly sophisticated queries on history--for example, you would be able to track a function across renames or just list all the names it ever had, which would be useful.
This is all possible, but writing a complete version control system is outside the scope of this side project. Additionally, it would be much easier to get users if this tool just augmented their existing workflow (e.g. Git) rather than trying to replace it altogether.
Hopefully this gives you a good idea of the sort of things I want to do. I have some other ideas as well, but some of them are probably too difficult to implement. I have to admit that even the relatively simple coffee I have so far turned out to be much more difficult to write than I exit expected.
Your question is actually very useful--it reminds me that I need to come up with a good elevator pitch for the system. I'll worry about it when I actually have a working prototype rather than a loose collection of slow functions :-).