As far as I know currently NTFS is missing a key feature for code developme nt 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 i n case project files are lost or corrupted.
There is a very clear and distinct need to include versioning in folders an d files.
I hope to see NTFS extended in the future to incorporate these changes/addi tional features.
I also highly recommend to include some GIT like versioning system integrat ion with windows explorer.
It would be highly desireable to "view/browse" and even edit or change prev ious GIT versions via a windows explorer and also to be able to open differ ent version folders/branches for code compare purposes and other editing to ols.
Currently this GIT integration is missing, tortuise GIT does offer some int egration/icon overlays but that's about it, advanced browsing of NTFS/GIT r elated 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 de ep branching and deep versioning of source code files.
GIT on top of NTFS would currently never be possible because of very limite d 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. Curr ently GIT is too limited in this and does not recgonize these changes in or iginal to be copied/rebased into split files. A very serious GIT limitation . This is "pattern recgonition" technology that must be advanced to the nex t level of technology. Perhaps DEEP learning might offer some possibilities here or new algorithms to detect "movements and code changes" of 1 file in to 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 ch anges of original fork maintainer, without original fork maintainer to comm it 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 sp lit 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 maint ainable and functioning. Compilers/Editors/Analyzers/Visualizers/Parsers th ese 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 t ools, especially if the large file was written by a person that does not kn ow the tools or the language well, strange bugs will occur especially but t hese kinds of programmers not knowing tool limitations and bugs.
Splitting off files can reduce these problems and solve them one by one bet ter and offer more possibility for diagnosis of tool-related bugs and probl ems, 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 w orks 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 scri pt did not work.
In principle I am against changing history in a versioning system, though t he re-base feature itself could be interesting if it works.
Think of this as "applieing a change in history towards the future", like t ime travel or something, perhaps a different term could be used for it.
"Apply change in past to future".
- Better visualization of history/branches.
Currently I cannot make sense of how branches are merged, this would be nic e 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 pr oject.
Though I still feel GIT currently falls a bit short in this, another contri buting 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 whic h 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
Other example:
version 0.10 based on version 0.03 of some other folder.
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 s peak.
It can be done but it's a bit weird.
Re-basing is dangerous also downloading and doing pull requests is dangerou s, especially if maintainer screwed up the git respository. I do not like t his 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 destinat ion 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:
- the remote
- the local working remote, whose changes cannot be changed by a download from remote with supervisor, this download should not be possible at all.
- the local download from remote, this one can be downloaded and then appl ied to the local 2.
For multi-user branching approach a better way might be to use the followin g:
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 e xplorer view/visibility.
Creating branches should be as simply as a copy & paste operation in window s explorer, and then renaming the copy.
This functionality could be integrated into the windows explorer pop-up men u.
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 suite d 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 mak e it more competitive with linux and git in general.
Bye, Skybuck.