A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Video Cards » Nvidia Videocards
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Extend NTFS with "version" of file and "version" of folder, alsooptionally GIT integration or something like it.



 
 
Thread Tools Display Modes
  #1  
Old November 19th 18, 05:43 PM posted to alt.comp.periphs.videocards.nvidia
[email protected]
external usenet poster
 
Posts: 533
Default Extend NTFS with "version" of file and "version" of folder, alsooptionally GIT integration or something like it.

As far as I know currently NTFS is missing a key feature for code development and compa "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.
  #2  
Old November 19th 18, 06:03 PM posted to alt.comp.periphs.videocards.nvidia
[email protected]
external usenet poster
 
Posts: 533
Default Extend NTFS with "version" of file and "version" of folder, alsooptionally GIT integration or something like it.

Described also as:

(Versioning System Integration with Windows Explorer)

Anyway

Googling NTFS and GIT turned up this:

https://blogs.msdn.microsoft.com/dev...l-file-system/

The objective of this project seems to be a bit different. To handle very large projects.

Which in itself is great. But for small projects like mine this is perhaps somewhat overkill.

But the people working on this project do have some experience integrating GIT with a file system and creating some virtual file system.

I highly recommend Microsoft to expand these kinds of projects massively or to expand this project in a big way and to involve Windows Explorer programmers to get on on this action and to expand windows explorer to also work with this file system and versioning system and to perhaps provide some slight new features for windows explorer to work in tandem with such a new file system.

I want something like this to be usuable for small projects too

Perhaps it's already usuable not sure... would be nice if this software could be made available for windows 7, only microsoft sort out the troubles with windows 10 updates

I think this continous windows 10 updating approach might be a bit too much for people to handle.

Perhaps it's better to have an older version and a new version, so people don't be bother with new version f*ck ups.

I sure don't have to to mess with windows updates and troubles, except very urgent security fixes.

Bye,
Skybuck.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
File Explorer "The action can't be completed because the folder/file is open in another program" John Doe Homebuilt PC's 6 December 31st 13 04:29 PM
Firmware version is still shown "same" after successful update? kimiraikkonen Storage (alternative) 2 July 31st 07 05:08 AM
Is Intel "Core 2 Duo" ALWAYS 64Bit ? Is the E4300 with 65 Watt the lowest power consumption version ? Peter Smirnov General 0 February 25th 07 12:50 AM
Acronis 10 and Vista x64: "failed to backup file or folder" "error reading the file" 0x40001 markm75 Storage (alternative) 0 February 24th 07 05:17 AM
Driver version 91.31 "Taskbar Icon" Greg Nvidia Videocards 6 June 28th 06 04:07 PM


All times are GMT +1. The time now is 12:16 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.