Re: [fossil-users] web UI for a working checkout?

2017-09-30 Thread Steve Schow 
Oh absolutely.  Its just fossil.  For me I can see two benefits to putting 
source on a public site like that.

1 - uptime.  Don’t have to worry about keeping my own fossil server up and 
running 24/7.  

2 - longevity, which is why I asked about that.  If I post some code on the 
internet, my desire will be for it to last pretty much forever.  Nobody uses 
source forge anymore, but you can still go there and download code that has 
been there a very long time.  The original author doesn’t have to worry about 
reposting it somewhere else again later.  Github is a fairly permanent source 
repository, I do not see that going away any time soon.  It will be around for 
decades.  Thus it is a very good place to place code that you want to not only 
work on publically, but just share with the world publicly and indefinitely.

However, I also do not like git much at all.  AT ALL.  You all know the reasons 
why already.  Besides the much discussed flaws with git, I just love that 
fossil has ticketing and versioning and wiki all built into one lightweight 
easy to install binary.  I tried messing around with all the other things 
people are using, and they were nightmare installs with MySQL or Postgres just 
to get started and basically way too complicated for small to medium projects.  
Plus they generally require you to use git…bleh..

Right now my thoughts are that if I create some kind of open source thing or 
something that I want to share with others, I feel like I would want to do all 
my work using fossil for tickets and version control, but then if I want to 
share my ongoing changes on github it would be a pain in the neck.

I guess chiselapp.com is pretty cool, if I find myself needing to do a 
multi-developer project or work on something where I hope others can 
contribute, then that would be better to avoid having to expose my own fossil 
server to the WAN.  I would get the uptime.  I’m pretty sure it will not last 
for decades, so I would have to consider this as most likely a temporary 
solution for publicly sharing the code on long term basis.

Fossil is so easy to install, its kind of a moot point…really don’t need it.  
Except for like I said..the two reasons above and keep your own server off the 
WAN.



> On Sep 30, 2017, at 12:34 PM, Andy Bradford 
>  wrote:
> 
> Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600:
> 
>> Who is hosting  that and what is the longevity  compared to github and
>> others?
> 
> Longevity on the Internet seems to  be an often nebulous thing. How long
> was Google Code (code.google.com) around? How long did Source Forge last
> before people started ditching it?
> 
> The nice thing  about chiselapp.com is that it's really  just Fossil. If
> chiselapp.com dies, you  still have your source (assuming  you clone and
> sync with chiselapp.com frequently) and it  wouldn't take much to find a
> new host to put it on.
> 
> Andy
> -- 
> TAI64 timestamp: 400059cfe3d8
> 
> 

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] web UI for a working checkout?

2017-09-30 Thread Andy Goth 

On 09/30/17 13:34, Andy Bradford wrote:

Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600:


Who is hosting  that and what is the longevity  compared to github and
others?


Longevity on the Internet seems to  be an often nebulous thing. How long
was Google Code (code.google.com) around? How long did Source Forge last
before people started ditching it?

The nice thing  about chiselapp.com is that it's really  just Fossil. If
chiselapp.com dies, you  still have your source (assuming  you clone and
sync with chiselapp.com frequently) and it  wouldn't take much to find a
new host to put it on.


One of the goals of Fossil was to transcend the problem of depending on
the survival and continued interest of others by producing an enduring
file format that can outlast any particular developer, software package,
hosting service, or even database system.  At heart, your Fossil
repository is what you see when you do a deconstruct: a collection of
artifacts, named by their checksums, tied together by manifests and
other structural artifacts.  The Fossil code base, the SQLite database,
the Fossil web site, the Fossil developers, and the Fossil community
exist to support this format, but should all these disappear, both your
development history and your development future are safe.

--
Andy Goth | 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] web UI for a working checkout?

2017-09-30 Thread Andy Bradford 
Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600:

> Who is hosting  that and what is the longevity  compared to github and
> others?

Longevity on the Internet seems to  be an often nebulous thing. How long
was Google Code (code.google.com) around? How long did Source Forge last
before people started ditching it?

The nice thing  about chiselapp.com is that it's really  just Fossil. If
chiselapp.com dies, you  still have your source (assuming  you clone and
sync with chiselapp.com frequently) and it  wouldn't take much to find a
new host to put it on.

Andy
-- 
TAI64 timestamp: 400059cfe3d8


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] web UI for a working checkout?

2017-09-29 Thread Steve Schow 
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  wrote:
> 
>> On 9/29/2017 4:43 PM, Steve Schow wrote:
>>> On Sep 29, 2017, at 2:46 PM, Andy Goth  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

Re: [fossil-users] web UI for a working checkout?

2017-09-29 Thread Roy Keene 



On Fri, 29 Sep 2017, Andy Goth wrote:


On 9/29/2017 4:43 PM, Steve Schow wrote:

On Sep 29, 2017, at 2:46 PM, Andy Goth  wrote:
Who is hosting that and what is the longevity compared to github and
others?


Roy Keene can answer these questions.



Roy Keene is hosting it... though, of course, so is everyone who clones 
their repos periodically.  Additionally, the source is hosted in 
ChiselApp.com in a repo called "flint".


It'll probably be around for a while, since I use it quite a bit... it was 
created and originally hosted by James Turner and I took it over from him 
when he was looking to move on to other things.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] web UI for a working checkout?

2017-09-29 Thread Andy Goth 
On 9/29/2017 4:43 PM, Steve Schow wrote:
> On Sep 29, 2017, at 2:46 PM, Andy Goth  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

Re: [fossil-users] web UI for a working checkout?

2017-09-29 Thread Steve Schow 

> On Sep 29, 2017, at 2:46 PM, Andy Goth  wrote:
>> 
> 
> http://chiselapp.com/ comes closest in that it provides a web interface
> for working on repositories as a whole.  It does not provide what you
> ask, nor do I know of any other web platforms that do.


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.  But that webui just looks pretty much 
like the same one built into the fossil binary, yes?Who is hosting that and 
what is the longevity compared to github and others?


> 
> The trouble is that in order for a checkout user interface to be
> meaningful, it needs to be bundled with tools to actually edit the
> checkout files.  Otherwise there's little point.  From the perspective
> of most programmers, web browsers can't compete with dedicated text
> editors, so what you describe will likely not be successful in targeting
> programmers.


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.  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 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.

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….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.

> 
> One thing that could happen is for "fossil ui" itself to get more
> checkout functionality, since it does indeed get used in combination
> with checkout editing.  Since it's used in conjunction with the command
> line, it does not make any effort to replace the command line.  But that
> doesn't mean it can't be an alternative interface, just like how it
> provides an alternative to diffing historical files from the command line.
> 


The key is that it would have to become aware of specific dirs which have 
checkouts in them and then provide a view of that checkout..including 
uncommitted changes, etc..



> Personally I'm not interested in "fossil ui" performing the checkout
> manipulations you describe, but nevertheless I would like it to be a bit
> more aware of checkouts, e.g. to diff the current checkout with its
> baseline check-in or other versions, to show the list of changes, or to
> show and manage stashes.


Right, well it would be great if we could see what exactly is GOING to be 
changed if we decide to commit, for example.  Compare the working files in the 
checkout dir against what is in the DB…etc, etc..  those are just some of the 
simplest cases..

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.  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.  Having a file tree view of the actual dir tree would be 
useful too.  Actually editing the files through the web, as you suggest, I 
don’t think would be that interesting to most people, but never know.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.  Just one strange idea… 
 but that  isn’t the primary goal I’m asking for now just mainly want to be 
able to commit, update, changes, branch or a few basic operations against a 
.fslchkout where files have been updated over SMB somehow.



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] web UI for a working checkout?

2017-09-29 Thread Andy Goth 
On 9/29/2017 3:15 PM, Steve Schow wrote:
> Is anyone aware of any Web based ui for working with a working
> checkout?  I’m looking for the ability to have a web app that can
> basically execute things like commit, branch, update and other
> checkout related fossil commands, operating on a checkout directory
> tree located on the webserver of course…

http://chiselapp.com/ comes closest in that it provides a web interface
for working on repositories as a whole.  It does not provide what you
ask, nor do I know of any other web platforms that do.

The trouble is that in order for a checkout user interface to be
meaningful, it needs to be bundled with tools to actually edit the
checkout files.  Otherwise there's little point.  From the perspective
of most programmers, web browsers can't compete with dedicated text
editors, so what you describe will likely not be successful in targeting
programmers.

One thing that could happen is for "fossil ui" itself to get more
checkout functionality, since it does indeed get used in combination
with checkout editing.  Since it's used in conjunction with the command
line, it does not make any effort to replace the command line.  But that
doesn't mean it can't be an alternative interface, just like how it
provides an alternative to diffing historical files from the command line.

Personally I'm not interested in "fossil ui" performing the checkout
manipulations you describe, but nevertheless I would like it to be a bit
more aware of checkouts, e.g. to diff the current checkout with its
baseline check-in or other versions, to show the list of changes, or to
show and manage stashes.

-- 
Andy Goth | 



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

[fossil-users] web UI for a working checkout?

2017-09-29 Thread Steve Schow 
Is anyone aware of any Web based ui for working with a working checkout?  I’m 
looking for the ability to have a web app that can basically execute things 
like commit, branch, update and other checkout related fossil commands, 
operating on a checkout directory tree located on the webserver of course…


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users