Timeline for Can version control systems use the filesystem log to capture changes?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 5, 2015 at 21:31 | comment | added | Aleksandr Dubinsky | @MilindR I still doubt the file system history will reveal this intent. Why wouldn't I just rename the file with the intent of giving it a different purpose? It would be the easiest way to get rid of the old file and create a new one with the same (or similar) content. If you'd like the rename status to communicate intent, it would make sense to let the user specify/modify that while making the commit. | |
| Nov 5, 2015 at 13:36 | comment | added | Milind R | What if that new file was not doing the same thing as the old one? The content might be the same for now, but it's purpose is different and will evolve differently. | |
| Nov 4, 2015 at 12:45 | comment | added | Aleksandr Dubinsky | @MilindR I would disagree with you there. No matter what I did with the file, if the content of the new file is the same, I would want my vcs history to be "optimized" to show a rename. I always aim for the history to be clean, and the minutiae of how I messed up my file manipulations especially should be hidden. God forbid I start to pay attention to that. | |
| Nov 4, 2015 at 4:25 | comment | added | Milind R | I very much understand that the challenge is in going higher-level. But the point I should have mentioned earlier is that there is a fundamental difference in renaming a file, and deleting it and getting the same thing from elsewhere with a different name but same contents. The former should result in a rename operation in a commit, while the latter should result in the disappearance of one file and appearance of the other : the new file and the old file are not related and so their histories should not be tied. | |
| Nov 3, 2015 at 15:47 | comment | added | Aleksandr Dubinsky | @MilindR As an additional indicator, it may be helpful, but like I hinted at, there's multiple ways to "rename" a file, and simply looking at the fs operations will only reveal the most obvious way. But you didn't answer my question. Beside tracking renames/moves, what else will you accomplish? Those are easy to detect anyway (edit distance). The tough part is handling merge conflicts. What might be most useful there is not going lower-level, but going higher. Ie, tracking refactoring operations like renaming of variables. | |
| Nov 3, 2015 at 12:01 | comment | added | Milind R | My intuitive idea was that seeing a rename operation will help understand why one file vanished and another appeared. Ultimately of course we'll keep a coarse grained commit log, but we can use more information to select the best boundary. | |
| Nov 3, 2015 at 11:58 | comment | added | Aleksandr Dubinsky | How does having a long and fine-grained list of changes help you solve the merging problem? It only makes it worse. | |
| Nov 3, 2015 at 11:55 | comment | added | Milind R | True. Two ways of mitigating that : 1) use a file system driver to capture how much ever is possible. 2) use both approaches, and form a master list with the more fine grained of the two. | |
| Nov 3, 2015 at 11:53 | review | First posts | |||
| Nov 3, 2015 at 13:07 | |||||
| Nov 3, 2015 at 11:51 | history | answered | Aleksandr Dubinsky | CC BY-SA 3.0 |