Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



Right now it's just a better diff/merge tool. It's more accurate than a normal diff or merge, doesn't get confused by meaningless changes, can resolve more conflicts (theoretically) and should be able to produce a much better interactive merge experience.

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 :-).


The biggest benefit is more clear understanding of changes in development teams over significant periods of time. For example, when was this function changed? That's very hard to answer when the diffs are not semantic.

The Eclipse IDE provides semantic diffs on top of version control when viewing specific commits (pending or already committed) but this is obviously not part of the underlying version control system and is limited.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: