As far as I know currently NTFS is missing a key feature for code development and compare: "versioning information" per file and per folder.
This sucks badly. Currently I have files as follows: folder version 0.01\ some_source_code_file_version_1.pas some_other_source_code_file_version1.pas and folder version 0.02\ some_source_code_file_version_2.pas some_other_source_code_file_version2.pas Now it's impossible to "code compare" these files with "code compare" tool. It does not recgonize these files. For code compare to work it would have to be: folder version 0.01\ some_source_code_file_version_1.pas some_other_source_code_file_version1.pas and folder version 0.02\ some_source_code_file_version_1.pas some_other_source_code_file_version1.pas However losing versioning information per file is dangerous in case folders are renamed or files are moved. Encoding versioning information in project files is also highly undesired in case project files are lost or corrupted. There is a very clear and distinct need to include versioning in folders and files. I hope to see NTFS extended in the future to incorporate these changes/additional features. I also highly recommend to include some GIT like versioning system integration with windows explorer. It would be highly desireable to "view/browse" and even edit or change previous GIT versions via a windows explorer and also to be able to open different version folders/branches for code compare purposes and other editing tools. Currently this GIT integration is missing, tortuise GIT does offer some integration/icon overlays but that's about it, advanced browsing of NTFS/GIT related folder tree structure is currently not possible cause ofcourse this functionality is missing. Furthermore deep branching is desireable to allow very deep folders. Also file path and folder path lengths must be incredibly large to allow deep branching and deep versioning of source code files. GIT on top of NTFS would currently never be possible because of very limited path and folders length. A little bit of branching and it hits limits. Also for a next-generation GIT version the following features are desired: 1A. Splitting of original source code file into multiple small files. + 1B. Rebasing changes in original split file into multiple small files. Currently GIT is too limited in this and does not recgonize these changes in original to be copied/rebased into split files. A very serious GIT limitation. This is "pattern recgonition" technology that must be advanced to the next level of technology. Perhaps DEEP learning might offer some possibilities here or new algorithms to detect "movements and code changes" of 1 file into multiple files. This feature will allow: 1.1. Splitting files into multiple files, without approval of original fork maintainer by "rebel" fork maintainer. 1.2. Continueing to work on multiple files by "rebel" fork, and rebasing changes of original fork maintainer, without original fork maintainer to commit these changes (from "rebel fork"). For as long as the pattern recgonizer can handle these differences it would be nice to have. Currently GIT is limitted to splitting files by maintainer, forks cannot split files and then continue to benefit from original unsplitted source, if original source does not split. Splitting files is in my oppinion necessary to keep software projects maintainable and functioning. Compilers/Editors/Analyzers/Visualizers/Parsers these are allow limited in their technology and implementation and can handle only so much due to limitations and especially bugs. The larger the source file the more like it is to contain some weird text which bugs out these tools, especially if the large file was written by a person that does not know the tools or the language well, strange bugs will occur especially but these kinds of programmers not knowing tool limitations and bugs. Splitting off files can reduce these problems and solve them one by one better and offer more possibility for diagnosis of tool-related bugs and problems, plus possibly higher recompile times since not entire file needs to be re-compiled. Also splitting files in relation to history and changing history/rebasing works bad currently in git as already indicated, somebody did write a script to try and solve it via branching per file, but as far as I know this script did not work. In principle I am against changing history in a versioning system, though the re-base feature itself could be interesting if it works. Think of this as "applieing a change in history towards the future", like time travel or something, perhaps a different term could be used for it. "Apply change in past to future". 2. Better visualization of history/branches. Currently I cannot make sense of how branches are merged, this would be nice if this was better indicated, ofcourse visualizating history of different time-related branches is more difficult because of more time/versions past and these "lines will run longer" especially in a multi-user/programmer project. Though I still feel GIT currently falls a bit short in this, another contributing factor to confusion is the "hashing" approach. Commits are numbered by "hash number", this kinda makes it harder to follow what branch is integrated/merged with what branch. For guy like me being used to seeing 0.01 and 1.03 and such this is not so ideal. I would like to see something like: version 0.01 and version 0.05 were integrated/merged. However this is not a branch by slight changes moved from 0.01 to 0.05 which would be a bit weird. Better example: version 0.05 main branch version 0.05 alternative branch integrate these two branches into version 0.06 or even back into version 0.05 main branch. Versions should be indicated as follows: version <version number> <version description> <base branch> Other example: version 0.10 based on version 0.03 of some other folder. version <version number> <base version> This way branches can be based on a base version. It's kinda thinking the other way around. The branch could and probably will become the main branch, and instead the version which it was based off is now history. Therefore re-merging is not required, and the branch can continue to run as main branch. This resembles evolution more appriorately and naturally then currently GIT does. In git a branch can be created of of a version number... but it will never become the main branch until it is merged back into main, this is wrong in some ways. However perhaps this example was more ment for creating new software based of older/different software and re-using it's source code base, so in that sense GIT may not be wrong, but does lack tracking of these "bases" so to speak. It can be done but it's a bit weird. Re-basing is dangerous also downloading and doing pull requests is dangerous, especially if maintainer screwed up the git respository. I do not like this at all, and want to keep my local versions 100% intact. Therefore there must be a disconnect between the remote and the local. A download from a remote must always re-create a local new version, to then continue work on perhaps. Re-incorporating changes from a remote to new local copy, to final destination copy where my work was done will have to be "supervised" to some degree, it can be partially automated, but user must indicate first that this is desired. This way there will always be 3 copies: 1. the remote 2. the local working remote, whose changes cannot be changed by a download from remote with supervisor, this download should not be possible at all. 3. the local download from remote, this one can be downloaded and then applied to the local 2. For multi-user branching approach a better way might be to use the following: version 0.05-Jack version 0.08-Skybuck version 0.06-Jason The branches created by the users are indicated by their username. However this doesn't really describe what the branch functionality is about but at least it does give some sense who worked on it but this is not the most important part. So a description of the branch is possible: version 0.05-Jack - New feature version 0.08-Skybuck - Further development of main version 0.06-Jason - Bug fixes Eventually these branches can and may be integrated into main 0.08 or 0.09. This branch description is very important and must be part of the windows explorer view/visibility. Creating branches should be as simply as a copy & paste operation in windows explorer, and then renaming the copy. This functionality could be integrated into the windows explorer pop-up menu. For example: "Rename version to branch" (this allows to copy main first and then decide if to branch it) "Create branch" (when sure it must be a branch, create branch directly) Eventually a branch can also be made main again. "Turn branch into main version" And some automation might also be nice: "Apply branch to main version" This would work by "copy" a branch by selecting it and then click copy, the instead of pasting it, it will be pasted into main. So it can also be called: "Paste branch into main" Or simply into folder or merge "Merge with" or "Merge changes with" for a slightly better description for new users. Windows Explorer and NTFS should evolve in such a way that it is more suited for "evolution like development of files" That would be very nice. This definetly means deep branching and perhaps some splitting and merging capabilities and change tracking plus history visualization. I hope to see some of this in a next version of windows, this will also make it more competitive with linux and git in general. Bye, Skybuck. -- https://mail.python.org/mailman/listinfo/python-list
