No the use case is not for development, just a simple use case of version control without command line access.
I agree, in real development situations everyone should have a cloned repo and work locally. Different use case. But the web GUI control over the checkout would still have usefulness even in a machine where someone has complete command line access, such as their local machine. If I roll something out it will have the ability, for example, to keep track of a current feature ticket and automatically add it with a commit. Being able to easily view a diff of what is about to be committed is very useful, etc... all can be made a bit more intuitive and even provide and overview such as always showing all currently changed files or a tree view that shows all files from the repo and unadded files colored differently, changed files also differently, etc. doing it in the web just also makes it useful on a headless box is all, regardless of whether you have shell access Sent from my iPhone > On Sep 29, 2017, at 5:33 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: > >> On 9/29/2017 4:43 PM, Steve Schow wrote: >>> On Sep 29, 2017, at 2:46 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: >>> http://chiselapp.com/ >> >> Hey thats pretty cool, I was not even aware of that site! I am going >> to check that out, I guess that’s a decent way to keep a repo public, >> then I can clone it here locally for working on stuff. > > Spread the word! > >> But that webui just looks pretty much like the same one built into the >> fossil binary, yes? > > When you're viewing any particular repository, yes. Chisel provides > everything else surrounding the repositories. > >> Who is hosting that and what is the longevity compared to github and >> others? > > Roy Keene can answer these questions. > >> Primary interest right now is in using a headless machine that will be >> hosting a repo. And often users will not have command line access >> either. In the simplest case, I could set it up, with web ui access >> to the repo itself, but then always require them to clone the repo on >> another machine and do all their edits there and push their changes >> back to remote master repo. > > That is the basic arrangement Fossil was designed for. > >> But it turns out there is also a use case for them being able to add >> files and commits to the repo directly on the headless linux box >> without having to clone the repo to another client machine. > > I supposed one could call this a hosted development environment. Though > let me add to what I said earlier (needing an editor, etc.) to point out > that development is meaningless without testing. Unless the product > being developed is documentation and testing is accomplished by reading > the document as formatted by a browser, your users are going to want to > be able to compile and run whatever they are making. Will your web > platform provide that too? It's not totally out of the question, and > I've seen submit-your-code-and-we'll-run-it stuff before. I'm just > saying that there's a lot to consider before you reach the point that > what you've put together is actually useful. > >> I hear what you’re saying about no way to edit without command line, >> but actually it would be perfectly fine to have the check out dir tree >> accessible via SMB share.. Then they can edit the files over SMB. >> But without command line access there is no way for them to commit the >> changes into fossil. That’s where a Web UI for some of those commands >> would be useful. > > I would strongly advise against SMB over the public Internet. VPN may > work, also you can use SMB within the firewalls of your organization. > Basically you're sidestepping the requirement to provide a web interface > to file management and editing, which is fine. Just, like I said above, > remember that not only do you have to have file management/editing and > access to Fossil commands, but you also need to be able to build and > test whatever is being developed. The requirements snowball the more > you think about them. > >> But this could also be useful even when running fossil alone on a >> local desktop machine. Kind of like when you run “fossil ui” and up >> pops a web interface to the fossil repo on the local machine. Still >> edit the files with vi, etc, but the fossil UI basically accesses the >> DB right now…it doesn’t touch any checked out dir trees or provide any >> way to use the UI to do stuff on them…. > > Okay, now we're agreeing on something. The web interface has limited > cognizance of the checkout in which it is being run. It can highlight > whichever check-in is currently checked out, and (quite important to me > right now) /doc can serve the "ckout" version for instant feedback on my > markup, etc. More checkout-sensitive capability would be nice. The > examples I gave before are diffing the checkout and managing the stash. > > Yet, diffing is a strictly read-only operation, and managing the stash > is likely either read-only or doesn't affect the checkout files. > Providing web-driven manipulation of the checkout is a big step, one I'm > not opposed to, but one I don't think we've ever considered. > >> which is what I wish it could..then it could be a fairly platform >> independent checkout GUI….including over to headless linux boxes that >> might have a check out there also. > > Headless Linux boxes have never been a problem for most folks because of > SSH, X11, VNC, etc. > > Platform-independent GUIs however, that is an attractive concept. It's > one we already enjoy in many respects, so why not more, huh? > >> Ultimately I guess I will have to roll out my own, as I don’t think >> anything exists and I doubt there is much interest. > > Is there a reason why your developers can't clone their own repositories > onto their own machines and do their work there in the environment > that's most comfortable for them? > > If you need a shared server because everyone runs Windows at their desk > yet development must be done in Linux for various reasons, please > consider giving shell access to your developers. > > A note: even if everyone is working on the same machine, it's probably > best that they all clone their own repositories anyway. Otherwise they > will have to take turns accessing the shared repository file because of > coarse-grained locking. For example, I've noticed two opens can't run > simultaneously. > >> I have a use case in the short term for something very simple that can >> at least just commit file changes to the repo through a webui. >> Basically need to be able to point the web ui at a .fslckout db and >> then enable the user to call commit, update, branch and a few other >> simple things. > > You're providing a limited web interface to preselected shell commands. > >> Having a file tree view of the actual dir tree would be useful too. > > But isn't this already going to be made available through SMB? Also > you're going to expose many Fossil commands, why not "fossil ls" too? > The "fossil changes" command has options to list all files, not just the > changed ones, along with their change status. > >> Actually editing the files through the web, as you suggest, I don’t >> think would be that interesting to most people, but never know. > > That's a major project outside the realm of Fossil. > >> I’d personally love to see an editor that could display a diff in >> realtime as I edit the file, so that as I edit the file I can see >> highlighting to show what I have changed compared to what is the repo, >> for example. > > I'd rather have the diff update only when I ask it to, but that's just > me. Realtime diff updating is distracting and inaccurate. > > -- > Andy Goth | <andrew.m.goth/at/gmail/dot/com> > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
