> On Windows (which is what the "non-technical" people will probably be
> running) you cannot write to an executable file while it is running.
Again correct: we are mainly talking about Windows where an executable
cannot write to itself --> read-only it must be.
That brings us to the update
On 5/12/18, Chris Drexler wrote:
>
> OR (my use case now) I can provide one executable on that they start
> locally
> on their computer and point their web-browser to the localhost url. BAM
> documentation including version information. no handling of individual
> files
>
On Sat, May 12, 2018 at 5:35 PM, Chris Drexler
wrote:
> Does this make sense? At least from a workflow perspective?
>
Personally, i don't think so ;), but i tend to be admittedly pessimistic
when it comes to "oddball setups".
How do you expect to sync changes with such
Hi,
you are perfectly right with your assessment, I had other/additional use
cases
in mind targeting more non-developers.
Just to explain: e.g. developer/technical people are doing an analysis and
generate code as well as results. With fossil that's easy to keep together
and the (mostly, in my
On Sat, May 12, 2018 at 1:51 PM, Chris Drexler
wrote:
> Thoughts? If someone could hint me at the right place within the
> fossil code I could also try to provide an implementation.
>
IMO: every clone would not have that feature, so it would seem (to me) to
be of
Hi List,
IMHO it would be great to have the append VFS available from Fossil
so that I could create a single-file self-contained repository with
the repo being attached to the fossil executable itself
As such I could copy exactly one file and have everything in there:
* all files packed
6 matches
Mail list logo