Revision tracking of functions is more important than file names.
With git, and bazaar two differences are that one tracks code moves fairly well and one tracks file moves well. One was originally written mostly by someone managing a code base, and the other is originally written by a company doing an operating system. So you can see their priorities - one has lots of code it cares more about, and the other has a lot of files it cares more about. (There are quite a few other priorities and features that each have).
I guess tracking the code itself is much more important than tracking file renames - for me. Much more useful anyway.
However *both* are important parts of revision control.
Many times during development I might cut a function/class from one file and move it into another. I can't get reports of this information in a meaningful way with bazaar (or can I?).
Also I might accidentally move a file with the command line tools, change it, then add it in again to the revision control system. This is because I forget that I need to use the revision controls system of moves.
A system that can automatically track *code* moving around, then can see that a file has been moved/renamed. It shows you that the code has moved, which is often more important, than showing you the file names have moved.
However the system that can track file renames *when you tell it* can not automatically see that I moved a function from one file to another. Or see that I split a big file of code into separate pieces - that is I moved one file into five.
Well it could, and I think that's important. I often care about what has changed at a module level, but more often care about what has changed at a class level, or a at the function level. I even care about change sets at the module, package, and application levels.
Full text search could help dramatically here, however having the tools built into the revision control system is much handier - and probably quicker.
So I think you should be able to see that the 'bazaar is lossless' argument is not true... or is it? I think bazaar is still lossless, it just doesn't let you get at all that information yet - just the data.
In the future it would be possible given a bazaar tree to find where a function has lived, no matter which file it has lived in.
Caring about what is in the files, is more important than caring about the files themselves. So these tools that work with revision control systems should be able to say things like
'svn log my_superfunction'
and see a log of changes to my_superfunction no matter where it lives. Perhaps giving it a hint of which file to look in, or even provide the full text of the current function.
However would this mean that the revision control system would need to know more about the content it is storing? I think a lot of it could be generalised, like 'this is a block of code' could be defined as a C++ class, a C function, or a python function. These tools could probably even be built outside of revision control systems. There's probably some tool that can be used for this already?
What about the case where code moves from one repository to another? This is a common case in a lot of projects. It'd be nice to be able to tell your RCS that you copied this function from project X with the repository XX. Then have your same commands for looking at history automatically work. I think bazaar - with launch pad - is interested in doing this type of stuff, and probably GIT too. I think with bazaar you can already do this - tell it you're merging from a separate svn repository, and it'll copy all of the history. Well, for files anyway, not sure about separate functions. Mostly when you move code from one project to the other, the file names will not be the same.
It's all very interesting reading about these different systems, and the thought that goes into them. Mostly though, I'll probably still just use add del update and commit - with hopefully a bit more of push, and merge. I'm using bazaar more and more now, along with svn too.
I guess tracking the code itself is much more important than tracking file renames - for me. Much more useful anyway.
However *both* are important parts of revision control.
Many times during development I might cut a function/class from one file and move it into another. I can't get reports of this information in a meaningful way with bazaar (or can I?).
Also I might accidentally move a file with the command line tools, change it, then add it in again to the revision control system. This is because I forget that I need to use the revision controls system of moves.
A system that can automatically track *code* moving around, then can see that a file has been moved/renamed. It shows you that the code has moved, which is often more important, than showing you the file names have moved.
However the system that can track file renames *when you tell it* can not automatically see that I moved a function from one file to another. Or see that I split a big file of code into separate pieces - that is I moved one file into five.
Well it could, and I think that's important. I often care about what has changed at a module level, but more often care about what has changed at a class level, or a at the function level. I even care about change sets at the module, package, and application levels.
Full text search could help dramatically here, however having the tools built into the revision control system is much handier - and probably quicker.
So I think you should be able to see that the 'bazaar is lossless' argument is not true... or is it? I think bazaar is still lossless, it just doesn't let you get at all that information yet - just the data.
In the future it would be possible given a bazaar tree to find where a function has lived, no matter which file it has lived in.
Caring about what is in the files, is more important than caring about the files themselves. So these tools that work with revision control systems should be able to say things like
'svn log my_superfunction'
and see a log of changes to my_superfunction no matter where it lives. Perhaps giving it a hint of which file to look in, or even provide the full text of the current function.
However would this mean that the revision control system would need to know more about the content it is storing? I think a lot of it could be generalised, like 'this is a block of code' could be defined as a C++ class, a C function, or a python function. These tools could probably even be built outside of revision control systems. There's probably some tool that can be used for this already?
What about the case where code moves from one repository to another? This is a common case in a lot of projects. It'd be nice to be able to tell your RCS that you copied this function from project X with the repository XX. Then have your same commands for looking at history automatically work. I think bazaar - with launch pad - is interested in doing this type of stuff, and probably GIT too. I think with bazaar you can already do this - tell it you're merging from a separate svn repository, and it'll copy all of the history. Well, for files anyway, not sure about separate functions. Mostly when you move code from one project to the other, the file names will not be the same.
It's all very interesting reading about these different systems, and the thought that goes into them. Mostly though, I'll probably still just use add del update and commit - with hopefully a bit more of push, and merge. I'm using bazaar more and more now, along with svn too.
Comments