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>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
