I think a git client would be a great addition to the stable of initial apps. SAFE support would bring some compelling features to the table. The main one being quick access to all my private and public repos on any computer.
I’m not exactly sure what the semantics would look like. It would be nice to avoid cloning the entire repo to the local computer. Maybe a clone would not actually copy the entire repo, just setup a virtual “.git” directory. Commits would remain local and only put into the SAFE repo when pushed. You would still need to be able to do all your standard history review and checkout from the entire repo in the network.
Developers are generally early adopters and this could solve some real problems. It could be a good introduction into what is possible.
Agreed. Git system on the SAFE network would indeed be nice to have.
Not sure what you mean by “local computer”. Do you mean your native filesystem? I would not want to have anything on the local filesystem if I could.
If the git repository is on the network, the clone’s could also exist in your drive portion of the network. You could reduce things like the time taken to clone a repo drastically as all you would be doing when creating a clone in your VFS drive is just getting the Directory Listing for that repo and it’s accompanying data maps. This might almost be instant. Only when you go to compile might the source’s even be retrieved or the client app could tweak that how ever it see’s fit.
There would be a ton of such small but better experiences we could bring to such a client with careful consideration.
Yep native filesystem. In the long term, yes it would be awesome if we could store all files on SAFE, even the working directory. In the first versions of the system, I would be surprised if it will be efficient enough to do this. You are better informed on what the current system can do though.
Compiling and other project level tasks must work just as quickly as they do now.
It is also important to be able to have multiple working directories for the same repo. Multiple people working on the same code base will want to have their own working directory and be able to manage their “local” commits before pushing into the central shared repo.
The way data is handled on SAFE and the integrated version control makes me think this would definitely be doable. The git repo could effectively just be a chain of versions explicitly defined by the user, with some metadata. The git version would just be a pointer to the maidsafe version of the working directory that the user chooses. Checking out a git commit would be as simple as changing the directory pointer in the VFS to point to the correct version on SAFE. It would be nice to be able to set different versions to have different permission levels, which I don’t think it currently possible.
This is a pretty fundamental change to how git does things, however. This sort of thing could be a fundamental component of maidsafe to allow users better control of versions and history. I could see an Apple time machine type application built on top of this.
It seems to me, it would be much easier to take git and tweak how pushes/pulls/clones work to integrate it into maidsafe. Also, it would be easier for users to pickup and understand as it is just like their current git, with a few tweaks to make it awesome. You wouldn’t even need fuse installed; you could distribute it as a self contained git client.
Reworking git to efficiently use the VFS drive looks like a lot more work to me. And it would be a harder sell to users that have never heard of Maidsafe.
True compiling is quite an involved process with the amount of intermediary files written and deleted before a single lib or exe gets spit out by the system. I guess once testing starts, we will all find out if this is achievable even in the early days.
Absolutely, here I was just referring to a git like structure. So you got your remote and local on the SAFE network. The local clone could be in your private drive part when the remote portion could say be from a share(private/public). So when you commit and push, you’re pushing to another part of the network. This should keep the functionality of this modified-git alike quite simply while giving you exceptional amounts of de-duplication when dealing with multiple local clone’s
As to writing a git-like app that uses the network’s versioning itself, that might indeed be a more involved project with a lot more things to tackle and implement. Something that might be more efficient but would require some serious time.
Let’s see once the Example’s project starts rolling out and we get to some app example stages we could revisit this topic and consider if it might be feasible and useful to have an example or two about implementing such a system. Maybe git or svn or something along the lines for source-control.
once the Example’s project starts rolling out and we get to some app example stages we could revisit this topic and consider if it might be feasible and useful to have an example or two about implementing such a system. Maybe git or svn or something along the lines for source-control.