Re: [fossil-users] remote check in

2016-10-24 Thread Warren Young 
On Oct 24, 2016, at 2:59 PM, Warren Young  wrote:
> 
> There is an experimental (?) feature of Fossil allowing it to operate as a 
> FUSE filesystem.

I’ve just peeked into the code for that, and it appears the Fossil fusefs 
feature is read-only.

If someone were to make this FuseFS feature understand filesystem modification 
operations, such that each modification caused a Fossil checkin, then my 
hypothesis that it would break many real-world software build systems would be 
testable.
___
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] remote check in

2016-10-24 Thread Warren Young 
On Oct 24, 2016, at 2:32 PM, Adam Jensen  wrote:
> 
> On 10/24/2016 03:07 PM, Warren Young wrote:
>> I don’t know that Fossil is all that close to any other software 
>> system you’ve likely used before.
> 
> Isn't it a file (version) management system based on an embedded database?

Under casual inspection, Fossil presents itself to the user that way, but if 
you dig into the way it actually works, you quickly find many places where 
Fossil doesn’t behave like a POSIX filesystem.  (Or an NTFS one, for that 
matter.)

1. Fossil’s file storage mechanism isn’t fundamentally hierarchical.  If you 
have a file called foo/bar/qux.c checked into the repo, its stored name is 
“foo/bar/qux.c” not “qux.c” which happens to live in a directory called “bar”.

2. Fossil’s low-level storage mechanism doesn’t have any concept of directories 
except as parents of a file, which is all Fossil really cares about.  Largely 
this follows from point 1, but there are other knock-on effects, such as that 
you can’t store an empty directory in Fossil.

3. Symlinks continue to have impedance mismatch problems w.r.t. POSIX 
semantics.  For example, there was the fix merged into trunk just 20 days ago 
allowing a symlink stored in Fossil to point to a directory.  Unix solved this 
in 1983 with the release of 4.2BSD, but Fossil didn’t implement this use case 
until 2016, which is the sort of thing that happens when you’re not setting out 
to build a POSIX filesystem from the start.  (I’m not laying blame, I’m just 
pointing out that different goals get different results.)

4. fossil mv and rm don’t behave like POSIX requires unless you give --hard or 
build Fossil in a nonstandard way and set an option that’s cleared by default.

5. Fossil’s understanding of file permissions is pretty much just a 
least-common-denominator subset of the logical intersection of Windows and 
POSIX permissions.

There is an experimental (?) feature of Fossil allowing it to operate as a FUSE 
filesystem.  (fossil help fusefs)  I suspect if you tried to use it that way 
for any complex software build system — say, that of Firefox — that you’d run 
into one or more of the above problems, or perhaps others I haven’t cataloged, 
as the build system makes assumptions about POSIX semantics that Fossil simply 
doesn’t provide.
___
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] remote check in

2016-10-24 Thread Adam Jensen 
On 10/24/2016 03:07 PM, Warren Young wrote:
> I don’t know that Fossil is all that close to any other software 
> system you’ve likely used before.

Isn't it a file (version) management system based on an embedded database?

On 10/23/2016 06:13 PM, Scott Doctor wrote:
> My current workflow uses a database (was filemaker but switched to
> sqlite a while ago) like a library card catalog with notes and status
> fields.

It sounds like you rolled your own file management system; the
difference being that, with Fossil, the managed files are stored *in*
the database.

For a while I imagined it would be useful if the Fossil file management
system were also capable of tracking and referencing files that are not
stored in the database. But after thinking more about the requirements
and use-cases, Fossil is probably in a funky territory of being too
light-weight in its capabilities to be the solution, and too monolithic
to be incorporated into a solution.

It has however attracted/inspired several people from the
research/experimentation arena (to the mailing list) who need a
tool-suite that supports modern [science][1] with software engineering
and data analysis methods. Again, I don't think Fossil is the solution
to this open problem.

[1]: By "science" I mean knowledge engineering informed by
epistemological sophistication and a high traction with reality.

___
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] remote check in

2016-10-24 Thread Warren Young 
On Oct 24, 2016, at 11:33 AM, Scott Doctor  wrote:
> 
> The issues I initially had with fossil were due to a misunderstanding about 
> how fossil works. An issue is that clicking the help button in the fossil UI 
> gives a wall of commands.

If the repository’s /help URL is where you started to learn about how Fossil 
works, no wonder you’re confused. :)

Have you read the Schimpf book, at least through chapter 3?

   https://www.fossil-scm.org/schimpf-book/doc/2ndEdition/fossilbook.pdf

Your issue comes up on page 31, which might seem late in the discussion for 
something so fundamental, but if you look at the table of contents, you can see 
that it’s just because the author wanted to cover other more fundamental things 
first.

The equivalent to the repo’s /help URL doesn’t appear until two chapters later 
in the Schimpf book, because /help is a command reference, not a tutorial.

> I think the documentation should group the most commonly used commands from 
> the master list.

I don’t think trying to contort the command reference into a tutorial will 
solve the base problem.  Prose works better than command lists for bringing new 
users on board.  Thus the Schimpf book.

And if you say, “Why didn’t I see this before?” then I’ll point out that it’s 
the fifth link on the Docs page at fossil-scm.org. :)

The first link on that page takes you to a Quick Start guide, and in the Making 
Changes section, it *does* talk about autosync, which is how local changes 
update the remote repository that you cloned from.

> It seemed as though fossil was basically a ticket/wiki database that had a 
> fancy way of zipping groups of files together.

You’re going to get into a lot of trouble trying to think of Fossil as a fancy 
sort of zip file.  That’s a wholly unhelpful abstraction.

What is Fossil like?  H.  I feel like a zen master being asked about the 
nature of butterflies.  Every analogy I can think of either breaks down too 
quickly to be useful or it gets into details too quickly to be helpful.

I mean, I can’t exactly just point you at this:

   https://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

and expect you to go, “Oh, of course that’s how it works!” :)

I don’t know that Fossil is all that close to any other software system you’ve 
likely used before.  It isn’t even all that much like its close competitors, 
Git, Mercurial and such.

You sound like you might be a research scientist, or IT support for research 
scientists, so how about this for an analogy: Fossil vs Git is like Mathematica 
vs Maple, or Origin vs. Gnuplot.  And Fossil vs Zip is like Mathematica vs. 
Python, or Origin vs. Excel.  You can draw parallels between each of these 
pairs, but to call them interchangeable is to misunderstand at least one of the 
alternatives.

It’s best to just take Fossil on its own terms, and not to try to think of it 
as like anything else you’ve ever used.  Fossil is Fossil.

> I derived that clone basically sent a zipped package of files

Better to say that clone retrieves the complete history of the project, not 
just files, but also wiki pages, checkin comments, branch and tagging info, 
tickets, etc.

The only overlap between the way Fossil artifact data are stored and how zip 
files work is that the zlib compression library used by Fossil to do lossless 
compression of data at rest and on the wire is more or less the same thing as 
the compression algorithms used in Zip files.

But unlike zip files, Fossil doesn’t model a hierarchical filesystem at its 
core, and zlib vs zip totally ignores delta compression, which has far more 
practical effect on the final size of a typical Fossil repository.

And even that aside, that view of Fossil ignores many other things like tags, 
branches, tickets, artifact IDs, etc.

> then someone manually has to conditionally decide what to merge back into the 
> main repository.

In a normal software development project, manual merges are rare.

However, your earlier description makes me believe you might be storing binary 
data, and on top of that, the data itself might be totally different each time. 
That is, unlike with software source code, your use doesn’t amount to evolving 
text files by relatively small amounts on each checkin.  That will prevent 
Fossil’s automatic conflict resolution from working, which means you’ll have to 
resort to social means to work out such conflicts.

> The documentation seems to imply that only the local copy is modified

Which documentation, specifically?  There’s a lot of it.

I’m still not sure if you just started in the wrong place or if one of the sane 
newbie entry points really does need to be improved.

> The documentation seems to read as though to get the local copy back into the 
> main repository requires a bunch of commands need to be executed on the 
> server command line.

This is an example where I need a specific URL to understand your problem.

> A problem with most manuals

Re: [fossil-users] remote check in

2016-10-24 Thread Adam Jensen 
On 10/24/2016 01:33 PM, Scott Doctor wrote:
[snip]
> I think the documentation should group the most commonly used commands
> from the master list. Maybe make several groups presented in most-used
> to rarely-used groupings. A primer should avoid permuting the possible
> operations until later (it just adds to the confusion) and focus on a
> complete real example with the concepts explained as though the reader
> is seeing it for the very first time.
[snip]
> The documentation needs a newbie primer that better explains how commits
> and syncing works. I now mostly figured it out, but was initially
> discouraged because of the seemingly (incorrect) concept of operation
> for syncing with the main repository.
> 
> A problem with most manuals for many software products is that an
> assumption is made that the reader already understands the concept of
> operation. If the reader is confuzzled at the start, then explanations
> of the commands do not absorb without an understanding why it is being
> done.

Déjà vu

http://www.mail-archive.com/search?l=fossil-users%40lists.fossil-scm.org=subject:%22\[fossil\-users\]+Pedagogy+Think+Tank+or+Documentation+Framework+RFC%22=newest

But there isn't much of a feedback mechanism in the software engineering
process to harness and utilize this information - it's still all done in
a willy-nilly, back-channel, human-toil fashion.

C'est la vie
___
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] remote check in

2016-10-24 Thread Andy Bradford 
Thus said Scott Doctor on Mon, 24 Oct 2016 10:33:08 -0700:

> Regarding  my command  line comment.  Originally I  misinterpreted how
> fossil works.

Thank you for being candid about what made your misunderstand how Fossil
actually works. This is valuable information:

> The  documentation needs  a  newbie primer  that  better explains  how
> commits  and syncing  works.  I now  mostly figured  it  out, but  was
> initially discouraged because of  the seemingly (incorrect) concept of
> operation for syncing with the main repository.

Probably  a  review  of  the  Fossil documentation  is  in  order,  with
particular attention  being made  on how things  work from  a high-level
view.

Thanks,

Andy
-- 
TAI64 timestamp: 4000580e5224


___
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] remote check in

2016-10-24 Thread Scott Doctor 
Just to clear up some confusion. The issues I initially had with 
fossil were due to a misunderstanding about how fossil works. An 
issue is that clicking the help button in the fossil UI gives a 
wall of commands. That is fine if you already understand the 
concept of the base operations and just need a quick syntax 
reference. But when trying to learn fossil from scratch, 
confusion sets in when looking at most of the commands without 
an understanding of why/when/should it be used. As it turns out, 
most of the commands are not used on a normal basis which just 
confuses a newbie without knowing what is/not important.


I think the documentation should group the most commonly used 
commands from the master list. Maybe make several groups 
presented in most-used to rarely-used groupings. A primer should 
avoid permuting the possible operations until later (it just 
adds to the confusion) and focus on a complete real example with 
the concepts explained as though the reader is seeing it for the 
very first time.


Regarding my command line comment. Originally I misinterpreted 
how fossil works. Here is how I thought it worked based on the 
explanations how to use it. (Note this was my original 
interpretation and have since figured out how it really works).


It seemed as though fossil was basically a ticket/wiki database 
that had a fancy way of zipping groups of files together. 
Without understanding the concept how it works, I derived that 
clone basically sent a zipped package of files, you work on the 
files, then zip them back up and then someone manually has to 
conditionally decide what to merge back into the main 
repository. That is what I derived from the documentation. As 
such I initially saw fossil as a burden to use that did not 
really add any value to my workflow.


I was not aware that doing a commit or sync automatically 
updated the main repository. That should be the very first topic 
of discussion in the documentation (with a better explanation 
and example). The documentation seems to imply that only the 
local copy is modified, which is why I was confused about the 
server command line issue. I was trying to figure out how 
changes to my local copy made it back into the main copy on the 
server. The command line I was referring to was the command line 
on the server not the local workstation. The documentation seems 
to read as though to get the local copy back into the main 
repository requires a bunch of commands need to be executed on 
the server command line.


The documentation needs a newbie primer that better explains how 
commits and syncing works. I now mostly figured it out, but was 
initially discouraged because of the seemingly (incorrect) 
concept of operation for syncing with the main repository.


A problem with most manuals for many software products is that 
an assumption is made that the reader already understands the 
concept of operation. If the reader is confuzzled at the start, 
then explanations of the commands do not absorb without an 
understanding why it is being done.



-
Scott Doctor
sc...@scottdoctor.com
-

On 10/24/2016 08:18, Warren Young wrote:

On Oct 22, 2016, at 4:40 PM, Scott Doctor  wrote:

How do they do such over the internet without having command line access?

Are you actually saying that your fellow researchers don’t have access to the 
command line on their own workstations?

I do understand that some managed PC installations do try to turn off the local 
OS command terminal.  An IT industry columnist I follow calls such people the 
Value Prevention Society, because they frequently take actions to remove the 
value we should expect to get from user-owned PCs over mainframes and such.

If you actually do find yourself operating in such a benighted environment, you 
could build a GUI wrapper program around the fossil.exe binary.  I’m not 
talking about anything grandiose; maybe half a day of time in your favorite GUI 
builder.  You could do this in anything from VB to Tcl/Tk to HTML Applications. 
 You could probably even do it in FileMaker. :)

(Yes, I’m making a leap here that you’re using Windows.  Organizations that 
allow use of other OSes generally don’t even *try* to lock their users out of 
the local command line.)


Seems adding files, doing check-ins, merges, should all be part of the UI.

Someone has to do it.  Patches will be thoughtfully reviewed. :)
___
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

Re: [fossil-users] remote check in

2016-10-23 Thread Adam Jensen 
On 10/23/2016 06:13 PM, Scott Doctor wrote:
> 
> On 10/23/2016 13:59, Artur Shepilko wrote:
>> It's not clear what type of project the OP is trying to setup, whether
>> it's a programming-related project, or general document-repo type.
>>
> I am doing research where we may do a dozen iterations a day generating
> about 10-100MB of files per iteration. within a short period of time we
> will have well over a terabyte of information. My current workflow uses
> a database (was filemaker but switched to sqlite a while ago) like a
> library card catalog with notes and status fields. The files are a
> combination of analysis code,  text csv, binary, and documentation.
> Occasionally we find something and want to go back to older data and
> re-run the experiment with a few tweaks, or modify the analysis program.
> I have information overload and finding stuff, even with it cataloged in
> a database, is becoming a significant chore. So I am trying out
> different techniques, such as using fossil, to track the experiments and
> the large volume of information.


Welcome to the party, Scott. https://youtu.be/lv0o9Lw3nz0?t=3m44s

[My foray down that
road](http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23837.html)
___
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] remote check in

2016-10-23 Thread Scott Doctor 


On 10/23/2016 13:59, Artur Shepilko wrote:
It's not clear what type of project the OP is trying to setup, 
whether it's a programming-related project, or general 
document-repo type.


I am doing research where we may do a dozen iterations a day 
generating about 10-100MB of files per iteration. within a short 
period of time we will have well over a terabyte of information. 
My current workflow uses a database (was filemaker but switched 
to sqlite a while ago) like a library card catalog with notes 
and status fields. The files are a combination of analysis 
code,  text csv, binary, and documentation. Occasionally we find 
something and want to go back to older data and re-run the 
experiment with a few tweaks, or modify the analysis program. I 
have information overload and finding stuff, even with it 
cataloged in a database, is becoming a significant chore. So I 
am trying out different techniques, such as using fossil, to 
track the experiments and the large volume of information.


-
Scott Doctor
sc...@scottdoctor.com
-


___
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] remote check in

2016-10-23 Thread Ron W 
On Sun, Oct 23, 2016 at 8:00 AM, 
wrote:
>
> From: "K. Fossil user" 
> Date: Sun, 23 Oct 2016 00:51:40 + (UTC)
>
> I was wondering if it is possible to do EVERYTHING [Fossil related of
> course] in a browser.
> I guess in theory it should be, but in practice?
>

For documentation, this could be done. Fossil does part of this. Could be
improved.

For source code, this more complicated.

Sure, you could edit your source code in a webbrowser, But what about
building it? You either have to download your source files to build them
locally, or run the build on the server. Generally, this is considered to
make it too easy to commit untested changes.

Or you can edit your sources locally, build and test, then upload your
sources through the browser.

A better approach would be to make a GUI client application for Fossil,
similar to TortoiseHg. The most successful project to do this - that I know
of - is fuel-scm.org

Alternately, some IDEs still support command line version control
"providers". At least as of 2.5 years ago, SlickEdit did.  For several
years, I used Fossil through SlickEdit's GUI.
___
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] remote check in

2016-10-23 Thread Artur Shepilko 
It's not clear what type of project the OP is trying to setup, whether it's
a programming-related project, or general document-repo type.

>From personal experience, I once was facing the same question to assess
Fossil "general" viability. For this almost abstract task, Jim Schimpf's
pdf book [http://www.fossil-scm.org/schimpf-book/home] was of great help.
It also helped to focus our intended use of Fossil with our projects.

Back then we concluded that Fossil was best fit for development-type
project, as developers had no issues with command-line interactions, and
were familiar with VCS concepts and tools. QA team could also use Fossil
tickets through web-UI. However non-developer users would be simply
unproductive trying to learn the Fossil command-line for document
management, thus we chose a different approach for the document-flow
project types.

Fast-forward to present, as mentioned before, with Fuel the document-flow
gets somewhat more office-friendly.

Additionally, with the use of plugins, the developer interaction also gets
somewhat more linear, concealing the command-line for the routine tasks.
Here are a few Fossil plugins:

- Fossil plugin for IDEA-based IDEs [
https://plugins.jetbrains.com/plugin/7479]
- Fossil plugin for Qt Creator IDE, C/C++ [
https://github.com/nomadbyte/qtcreator-plugin-fossil]

Hope this helps.
___
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] remote check in

2016-10-23 Thread Ron W 
On Sun, Oct 23, 2016 at 8:00 AM, 
wrote:
>
> From: Andy Bradford 
> Date: 22 Oct 2016 20:48:42 -0600
>
> Thus said Scott Doctor on Sat, 22 Oct 2016 15:40:33 -0700:
>
> > The problem I am having is how to add files, do check-ins and such via
> > the  UI,  mostly regarding  doing  it  remotely without  command  line
> > access.
>


> There do exist tools  that wrap the commands  in a UI. For  example,
> TortoiseSVN,
> TortoiseGit, etc.
>
> I believe I have seen someone announce on this list a wrapper UI for the
> Fossil commands. Maybe search the archives?
>

That I have heard of, https://fuel-scm.org (there were a few others, but
they are too out of date).
___
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] remote check in

2016-10-23 Thread Steven Gawroriski 
On 22 Oct 2016 20:48:42 -0600
"Andy Bradford"  wrote:

> I believe I have seen someone announce on this list a wrapper UI for
> the Fossil commands. Maybe search the archives?

I believe it is called Fuel , as a
pun on Fossil.
___
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] remote check in

2016-10-22 Thread Andy Bradford 
Thus said Scott Doctor on Sat, 22 Oct 2016 15:40:33 -0700:

> The problem I am having is how to add files, do check-ins and such via
> the  UI,  mostly regarding  doing  it  remotely without  command  line
> access.

It isn't possible to commit files to the repository using the Fossil UI.

This is  also true for svn,  git, and most other  repositories. There do
exist tools  that wrap the commands  in a UI. For  example, TortoiseSVN,
TortoiseGit, etc.

I believe I have seen someone announce on this list a wrapper UI for the
Fossil commands. Maybe search the archives?

Hope this helps.

Thanks,

Andy
-- 
TAI64 timestamp: 4000580c252e


___
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] remote check in

2016-10-22 Thread Shal Farley 

Scott,

The problem I am having is how to add files, do check-ins and such via 
the UI, mostly regarding doing it remotely without command line access.


I'm far from an expert user of fossil, but I believe the normal setup is 
to have a local copy of the repository, where command line access is 
simple and direct, and use fossil's sync feature to deliver checkins to 
remote servers.


In a multi-developer situation each developer would work with their own 
local repositories, in sync with a common server.


Shal

--
Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


___
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] remote check in

2016-10-22 Thread Shal Farley 

K,

It would be helpful to the other members of this list if you would not 
chime in with provocative non-sequiturs when you don't know the answer.


Just my humble opinion.

Shal
(see, you trolled me out of my lurking state)

--

Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


On 10/22/2016 3:52 PM, K. Fossil user wrote:

Hi,

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
...
___
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] remote check in

2016-10-22 Thread K. Fossil user 
Hi,

>« So do people who have a check-in or a new file email
the file to the administrator and they add/check-in, or do those
people have command line access? »

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
3/ The purpose of SSH (long talk with the Fossil users) is to help people use 
secure remote command line...
(This is how I understand it)
4/ I was wondering if Fossil have got something that is not "command line". I 
dunno.


Best Regards

K.



  De : Scott Doctor <sc...@scottdoctor.com>
 À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> 
 Envoyé le : Samedi 22 octobre 2016 22h40
 Objet : [fossil-users] remote check in
   
I am trying to figure out how to use fossil for an upcoming 
project. I keep coming back to fossil as the alternatives (git, 
mercurial,...) are just... well I will go bald trying to figure 
them out. I made a test repository to play with and mostly 
figured out the command line commands. The problem I am having 
is how to add files, do check-ins and such via the UI, mostly 
regarding doing it remotely without command line access.

My question is, for example the sqlite fossil system, someone 
wants to check-in a change of a file, or add a new file. How do 
they do such over the internet without having command line 
access? I do not see any operations from the UI that does that. 
Seems adding files, doing check-ins, merges, should all be part 
of the UI. So do people who have a check-in or a new file email 
the file to the administrator and they add/check-in, or do those 
people have command line access?

-- 

-
Scott Doctor
sc...@scottdoctor.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

[fossil-users] remote check in

2016-10-22 Thread Scott Doctor 
I am trying to figure out how to use fossil for an upcoming 
project. I keep coming back to fossil as the alternatives (git, 
mercurial,...) are just... well I will go bald trying to figure 
them out. I made a test repository to play with and mostly 
figured out the command line commands. The problem I am having 
is how to add files, do check-ins and such via the UI, mostly 
regarding doing it remotely without command line access.


My question is, for example the sqlite fossil system, someone 
wants to check-in a change of a file, or add a new file. How do 
they do such over the internet without having command line 
access? I do not see any operations from the UI that does that. 
Seems adding files, doing check-ins, merges, should all be part 
of the UI. So do people who have a check-in or a new file email 
the file to the administrator and they add/check-in, or do those 
people have command line access?


--

-
Scott Doctor
sc...@scottdoctor.com
-

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