Re: [fossil-users] What should email notifications look like?

[Jan Danielsson]

On 2018-06-22 20:40, Joerg Sonnenberger wrote:
[---]
> BTW, the main mercurial list uses the following mail format for "batch"
> changes:
> 
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-June/117551.html

   This is highly machine parse-friendly.  I like it a lot.

-- 
Kind Regards,
Jan
___
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] Rumor: Microsoft has acquired github

[Jan Danielsson]

On 2018-06-04 02:24, Stephan Beal wrote:
>>> It does kind of make sense: the global leader in creating
>>> market-leading-yet-unusable software acquires one more piece of
>>> market-leading-yet-unusable software.
>>
>>This appeals to my sense of order.  :)
> 
> Though, to be fair: github goes to great lengths to make git usable, but
> with a piece of software so thoroughly misanthropic as git, one can only do
> so much.
   Agreed.

> We'll supposedly find out "on Monday" whether this rumor is true. It's
> already Monday in my timezone, but the news outlets don't seem to care
> about non-US timezones :/.

   Someone on twitter jested:  "Sign in with your Office 365 account to
access github.".  I think there are a lot of people a gritting their
teeth over that joke right now.

-- 
Kind Regards,
Jan Danielsson
___
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] Rumor: Microsoft has acquired github

[Jan Danielsson]

On 2018-06-04 00:35, Stephan Beal wrote:
[---]
> It does kind of make sense: the global leader in creating
> market-leading-yet-unusable software acquires one more piece of
> market-leading-yet-unusable software.

   This appeals to my sense of order.  :)

-- 
Kind Regards,
Jan Danielsson
___
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] "malformed database schema"

[Jan Danielsson]

On 2018-04-11 00:17, Stephan Beal wrote:
> i suspect that the old sqlite version has something to do with this. Try
> using "fossil sqlite" instead of sqlite3.

   D'oh!  Of course it is; I knew you were right before even trying.
Thanks!

-- 
Kind Regards,
Jan Danielsson
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] "malformed database schema"

[Jan Danielsson]

Hello,

   I made a fresh clone of https://src.fossil.NetBSD.org/ and it seemed
to run to completion without any problems, but once it's done I can't do
simple queries in it:

gauss$ sqlite3 netbsd.fossil

SQLite version 3.8.3.1 2014-02-11 14:52:19
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .schema
Error: malformed database schema (artifact) - near "(": syntax error
sqlite> select * from config;
Error: malformed database schema (artifact) - near "(": syntax error

   I redid the clone but it ended up in the same state.

   Browsing the source online repo seems to work fine, so I'm assuming
it's a local problem -- but how can it end up in this state?  I did no
more than clone it.

-- 
Kind Regards,
Jan Danielsson
___
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] Cannot clone repository over SSL

[Jan Danielsson]

On 07/08/17 15:34, Walter Paganini wrote:
[---]
> Any idea about what might be causing this issue and how to solve it?

   Not specifically, not without seeing your nginx configuration.
Though I recall having seen someone post a how-to on how to put fossil
behind an nginx, and I believe there's even a page for it on fossil's
wiki.  You could start by comparing that to your configuration.  (That
said, I haven't actually followed that guide; I don't recall if it was
for SSL, and nor do I know if cloning works through it).


-- 
Kind regards,
Jan Danielsson

___
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] How do I report a problem on the Fossil Web site?

[Jan Danielsson]

On 04/13/17 06:17, Ryan Dingman wrote:
> Its strange that this thread is coming up now because I’ve been working on a 
> patch to implement #4 for the past couple of weeks. My motivation for doing 
> so was to have integration with the macOS Keychain and gain the ability to 
> pull client certificates from it rather than having to load them from a PEM 
> file on disk.

   I'm all for idiomatic approaches.  That said:

   - Will it work without a gui (i.e. when you log in via ssh, will you
be able to access the private key from the keystore without entering
your password on a desktop prompt)?
   - Compatibility with "use PEM file on disk" needs to be retained on
Mac.  I have scripted build systems which run on NetBSD, macOS and Linux
which clone repositories using client certificates.  These scripts
quickly become a pain to maintain when there are too many differences
between the platforms.

[---]
> I need to do a bit more testing, but if there is community interest, I’d be 
> happy to accelerate my plans and submit a patch to Dr. Hipp soon.

   There's definitely interest.

   In the original client certificate support for fossil, there was one
extra level of indirection; instead of pointing out a file, one used a
symbolic name (which would point to a file in the "PEM in disk" case),
but the idea was that this could be used to point to other locations,
such as an entry in a keychain.  I'm curious to see how your solution
works with regards to client certificates/keys.

-- 
Kind regards,
Jan Danielsson

___
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] SSL on Mac

[Jan Danielsson]

On 04/13/17 13:25, Stephan Beal wrote:
>>>> did anyone come up with a solution to SSL on Mac problem?
>>> Can you remind us what the "SSL on Mac" problem is?
>>
>>I believe the issue stems from that Apple decided that OpenSSL is
>> uncool and everyone should use their system (Objective-C) library
>> instead.  The dynamic OpenSSL libraries remain in the system for
>> compatibility, but they no longer include the headers -- so when you
>> build fossil on new:ish Macs (read: XCode), build systems tend to find
>> non-system instances of OpenSSL and use them instead.
> 
> What if, instead of #including the openssl headers, fossil simply declares
> the few external interfaces it uses in its own sources?

   That's one possible solution, but imho it's a pretty ugly band-aid.
I think it's better to go back to the original idea of using
statically-linked libraries for the pre-built binaries.  That way when
Apple decide to eliminate the dynamic libraries as well (not that I
think they can do that any time soon) the monolithic fossil binary will
continue to work.

-- 
Kind regards,
Jan Danielsson

___
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] SSL on Mac

[Jan Danielsson]

On 04/12/17 19:11, Richard Hipp wrote:
>> did anyone come up with a solution to SSL on Mac problem?
> Can you remind us what the "SSL on Mac" problem is?

   I believe the issue stems from that Apple decided that OpenSSL is
uncool and everyone should use their system (Objective-C) library
instead.  The dynamic OpenSSL libraries remain in the system for
compatibility, but they no longer include the headers -- so when you
build fossil on new:ish Macs (read: XCode), build systems tend to find
non-system instances of OpenSSL and use them instead.

-- 
Kind regards,
Jan Danielsson

___
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] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

[Jan Danielsson]

On 03/26/17 19:18, Richard Hipp wrote:
[---]
> (i)  With Fossil, one can click on two nodes of the graph to see a
> diff between those two nodes.  With GitLab, you apparently have to go
> to the separate "Compare" screen, then many type in (or paste in) hash
> name prefixes of the two check-ins you want to compare.  This seems
> rather clumsy.  But maybe I'm missing something.

   This is the same in Bitbucket.

   I use the version compare feature in the timeline in Fossil *a lot*;
I'd almost be willing to stretch to say "literally daily", but I'm sure
there's been a day when I haven't used it -- but you get the point.

   When I helped install a development environment based on the
Atlassian products a while ago I was quite shocked that Bitbucket didn't
support the feature.  Considering how useful it is, I had never occurred
to me that a modern UI _wouldn't_ have it.

   Anyway, I searched around to see if it was available in an alpha
version or something somewhere, and quickly realized others wanted the
feature as well.  However, no good news on that front:  The idea was
apparently "No, you use tool X for that.".  (As it happens, this tool X
was a desktop application for the local checkout, which - in my mind -
kind of defeated the purpose).

   Maybe this is tangentially related to the cathedral vs bazaar
discussion; with Fossil, you typically have a central point where "all"
the useful checkins end up.

-- 
Kind regards,
Jan Danielsson

___
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] Proposed roadmap for Fossil 2.0

[Jan Danielsson]

On 03/01/17 17:06, sky5w...@gmail.com wrote:
[---]
> 3. Fossil 2.0+ delivered as dll.
>I use the exe for remote repo server, but automate my check-in/out's.
>That would be more fluid without parsing CLI text.

   This has brought up a few times before, and there are no such plans
(not for 2.0, 2.1 or beyond).  There's a separate project which is
designed to accomplish what you're looking for:
http://fossil.wanderinghorse.net/repos/libfossil

-- 
Kind regards,
Jan Danielsson

___
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] Git just got shallow and sparse clones

[Jan Danielsson]

On 2017-02-04 14:07, Konstantin Khomoutov wrote:
> On Fri, 3 Feb 2017 09:00:54 -0700
> Warren Young  wrote:
> 
>> https://developers.slashdot.org/story/17/02/03/1427213/microsoft-introduces-gvfs-git-virtual-file-system
> 
> Care to elaborate a bit?
[---]

   Granted, I just skimmed a few seconds, but I got the feeling that the
new feature makes it look like it has a bunch of stuff checked out when
it really hasn't.  And once you try to access files which haven't been
fetched before, it fetches them for you.

   So when you do your initial clone, it only downloads some metadata
about what files exist in the repository, but not the contents of them.
When you open a file, the vfs will fetch the file for you.

   Say a project has a doc/ directory which is unrelated to the build
process, and there are 200MB worth of documents in there.  A person who
just wants to build the project probably doesn't want to download all
those docs, so they just kick off the build without touching the files
in doc/.

   Like I said, I only skimmed a few seconds so I could be way off, but
that's what it looked like to me.

   If it is what I think it is:  With all these indexing tools out
there, scanning every file it finds, I wonder how useful this feature
really is?

-- 
Kind Regards,
Jan
___
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] tags manifest

[Jan Danielsson]

On 05/08/16 02:51, Ross Berteig wrote:
[---]
> I just created test cases for fossil set manifest that verify that the
> files manifest, manifest.uuid, and manifest.tags appear and disappear as
> the setting is changed. I did not verify that any of the files have the
> right content.

   Many thanks; this saved me a lot of time, as a non-native tcl
speaker.  And as such, I also would like someone to quickly look over
the additions I've made.  It seems to work, but I have a feeling I have
have reinvented the wheel.

>> I'm not sure offhand how our test coverage looks for all settings.
>> Writing tests that cover every setting is probably a worthy goal for a
>> long term and low priority project for someone who wants to visit all
>> the nooks and crannies in the fossil source kit.
> 
> On the assumption that there will be more tests related to settings, I
> named the new file test/set-manifest.test so there is an obvious naming
> pattern to follow for tests of other features primarily exposed through
> settings.

   I added more tests in the same file, but given the "set-" prefix I
assume it would have been better to split the manifest.tags content
tests to a separate test.  On the other hand, there aren't many tests
overall so it doesn't hurt having them all in a single file for now.

-- 
Kind Regards,
Jan
___
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] tags manifest

[Jan Danielsson]

On 04/08/16 20:44, Warren Young wrote:
>> That's one of the things I realized after a few
>> failures -- whatever scheme you come up with, it has its limitations.
> 
> That’s part of what I mean, but I’m not just talking about simple 
> limitations.  The second and third applications of the code in new contexts 
> often stretch the original design in ways you had no reason to even consider 
> when initially designing the feature.
> 
> This is why too much up-front design is a problem.  It isn’t until you begin 
> trying to apply the design to the real world that you can see all of your 
> initial design’s weaknesses.

   Sure, and it's appreciated.  We've been using it for well over half a
year, and have formed some build systems around how the feature works.
And it would be naive to say I don't suffer from some tunnel-vision.

   That said, I explicitly didn't want to invent a complete new big
system.  I wanted to simply expose data which is already there in a
simple-to-access manner and - importantly - allow the information to be
accessed in tarballs and zipfiles.  There's a lot more one could do if
one were willing to do more plumbing, so to speak.

[---]
> Given the behavior you show, I wonder if your feature should create 
> manifest.branches, not manifest.tags.

   The way I view it is that it's used more like a label than anything,
and in that sense "manifest.tags" is more fitting.

   On a more technical note:  I use a query from "tags list" source to
generate manifest.tags.

>>> Does your build system use this project name to detect which binary 
>>> package(s) to build?
>>
>>   Sorry, I don't understand the question; interpreting from context
>> I'm going to take a stab at answering.  I apologize if I completely
>> misunderstood (it's well past bed-time here..).
>>
>>   The build server gets a request to build a specific version.
> 
> I was operating under the assumption that you had some kind of Continuous 
> Integration system going, so that every checkin could trigger a build, so the 
> CI system would need a way to figure out which binary packages to build: 
> release client, release server, experimental development builds of both, etc.

   No; some components have nightly builds, but there's still too much
manual intervention required for some of the near-leaf-node builds.  I
have worked in places which use CruiseControl and Jenkins; and there's a
long-term goal to use a CI-system here as well, but .. so many other
things on the todo-list..


-- 
Kind Regards,
Jan
___
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] tags manifest

[Jan Danielsson]

On 04/08/16 00:08, Warren Young wrote:
>> This means that the same
>> information is available in two different places
> 
> Only two?  Aren’t you the lucky one. :)

   Not that lucky, unfortunately.  :(  That was mostly referring to
cases such as sqlite and even fossil itself.  In our case it refers to
how some of the more recent repositories have been set up.  There are
old monolithic repositories which acted as "catch-all" repositories back
in the day and which we have been unable to break up for various
reasons.  They have many different components and versions in the same
repositories.  Then again, some of them are stuck in CVS and Subversion,
but my hope is to someday split them up as much as can possible be done
and convert them to fossil repositories..

> In my current main projects, the release version number appears in:
> 
> - the top-level build system file (configure.ac, CMakeLists.txt, etc.)
> - the most recent section at the top of the ChangeLog
> - the source file feeding “./myprogram -v” or the About screen
> - the binary package description file(s) (e.g. *.spec for RPM)
> - the Fossil release tag
> - the comment on the Fossil checkin creating the release tag
> 
> We drive everything from the first item on that list, except that the 
> ChangeLog remains manually-updated.  In that sense, we have “only” two places 
> to change the version number, too.
> 
> The formal release version number in our system has two parts: the 
> human-facing version number (e.g. 1.2.3) and the binary package release 
> number (e.g. -1) which combine to give the formal release number, 1.2.3-1.  
> These two parts may be in the same top-level file (e.g. CMakeLists.txt for a 
> CMake based project) or in separate files (e.g. configure.ac and *.spec.in 
> for an Autoconf + RPM based project).
> 
> We use the binary package release number to distinguish two different Fossil 
> checkins both tagged someproject-1.2.3.  The checkin comment for the first 
> tag will say “Release someproject v1.2.3-1”, and the second “…-2”.
> 
> The Fossil tag checkin and its checkin comment are generated by a mkrel 
> script we wrote which parses the version number out of one of the generated 
> files, such as *.spec file in an Autoconf + RPM based project, which as I 
> have said is generated from *.spec.in and configure.ac.
> 
> Other files come off of this, such as a version.h file for a C++ project, 
> generated from version.h.in by Autoconf, which gets it from configure.ac.
> 
> Because we want the binary package release number in the Fossil release tag’s 
> checkin comment, generated by the mkrel script, Fossil doesn’t get involved 
> until nearly the end of this process.  My initial thought from that 
> observation is that this means we can’t really replace our current scheme 
> with your scheme. If you had to redesign our scheme to use your new feature, 
> how would you go about it?

   Yeah, so you just perfectly summarized why versioning is a massive
pain in the you-know-what, and that tools even today are lacking in
helping manage version numbers.  And it gets really fun when people try
to be clever and have "funny" schemes like "the version converges
towards pi.".  (Which I myself thought was funny and clever until I
started writing tools for managing version numbers..).

   I can't answer your question without dedicating some time to it, and
I can't say that I would come up with an good manifest.tags-solution for
your specific case.  That's one of the things I realized after a few
failures -- whatever scheme you come up with, it has its limitations.

   There's much I can relate to in the procedures you described, so I
definitely understand where you're coming from.

> I don’t mean to dismiss your efforts, Jan.  It solves a real problem, and I 
> wish it was available before we started solving these problems on our own, 
> many years ago.  I’m willing to offer a weak sort of endorsement for 
> trunkifying it, since I haven’t played with it, but I can see that it’s 
> useful already.

   No worries, I didn't take it as a dismissal; but you're highlighting
something I should have been clearer about:  I was primarily aiming to
solve one particular problem for one, as I see it, fairly typical case.
Looking at the open source projects I follow closely, such a scheme
could be used for the majority of them.  That said, there are plenty of
cases where its use would be very limited.

>> Someone(tm) needs to make sure they match.
> 
> Or, as we have both discovered, some *thing*.  This is a task for automata, 
> not humans.

   Exactly.

>> Each new released version is tagged using a -
>> tag.
> 
> Tagged how?  Manually?

   Yes, but we have some tools to assist in that as well.  I have a
script which automatically tags "next version" (for fossil projects):

   $ revup major
   mytest-1.0.1 -> mytest-2.0.0
   $ revup minor
   mytest-1.0.1 -> mytest-1.1.0
   $ revup
   mytest-1.0.1 -> mytest-1.0.2

   ... but it has been kind of flaky, 

[fossil-users] tags manifest

[Jan Danielsson]

Hello,

   Since I've finally got a few days off, I've done some updates to the
jan-manifest-tags; merge with trunk, made some bugfixes, and thought I'd
reintroduce the branch (since it's been a while).

   The basic idea is the following:  It's common practice for projects
to tag new release versions of their software.  Separately from that,
there's a version number somewhere in the source tree (like #define
VER_MAJ 1, #define VER_MIN 2, etc).  This means that the same
information is available in two different places and Someone(tm) needs
to make sure they match.  The idea for a tags manifest-like feature came
about when I was working in a high-assurance project a long time ago and
it happened once or twice that due to human errors, the two versions
didn't match.  (not-so-high-assurance..).

   Tags manifests allows build systems to be able to extract the tagged
version information from manifests generated by fossil.  This has the
positive side-effect that the build system will work in tarballs and
zipfiles generated by fossil, as they will contain the manifest files
(provided the server has the appropriate manifest settings..).

   One addition (as per feedback) was to include the current branch at
the top of the manifest.tags.  It uses the special "branch=" prefix.
Note that this is only done when operating in an open working tree.
I.e. the branch=... will not be available in generated tarballs and
zipfiles, so don't make your build system rely on the "branch="-entry if
you want you want the build system to work in exported tarballs or zipfiles.

   How we use it:

   Each new released version is tagged using a -
tag.  Our build server checks out a clean copy of a tagged version.  The
build system iterates through each line of manifest.tags and looks for
-X.Y.Z (where X, Y, and Z are numbers).  Once found, it
either uses the version numbers to generate a header file, or a
-DVERSION=... argument to the compiler.  For non-release builds, such an
entry will not be found in manifest.tags, and it will use a special
version number to indicate it's a development build.

   Other uses include using special (propagating) tag names (like
"experimental") to make the build system take special actions.

   We've been using a version of the branch for a pretty long time now,
and I'm starting to feel that it's ready for trunkification.

   For those who are afraid of new features messing with your current
setup:  The jan-manifest-tags branch is explicitly designed to not
interfere with your current setup.  You need to take action for a change
to occur.  If you use "set manifest on" or "set manifest off" it will
work exactly like it always has.  I.e. if you don't care about this
feature, you - as an end user - will not notice it's there (apart an
updates settings field and help text).

   Thoughts?

-- 
Kind Regards,
Jan
___
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] backing up repo to cloud service

[Jan Danielsson]

On 02/05/16 22:17, Steve Schow wrote:
> I wish to include my fossil repos in backup to cloud backup service.
> 
> what is the best approach for doing this?  if a fossil operation is in the 
> middle of trying to do something when the automated cloud backup daemon 
> decides to backup the repo file, I am presuming the backed up file could be 
> in an inconsistent….non-atomic state.
> 
> Would it be preferable to do a sqlite dump or something of this nature and 
> back that up to cloud service?

   This is what I have done; not exactly what you're asking, but it can
be used to accomplish the same thing.

   I have set up a json interface which can be used to get a list of
repositories on our main development server.  A script on another system
will use this interface to clone any repository which hasn't been cloned
already, and pull changes from all the already cloned repositories.
Once this has been done all the cloned/pulled repositories are backed up.

   This has the added benefit that I don't need to store credentials for
logging in to the backup server on the main development system.

-- 
Kind Regards,
Jan
___
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] Getting time of last repository change

[Jan Danielsson]

On 11/04/16 17:17, Stephan Beal wrote:
[---]
>>Is there a timestamp for when artifacts where locally added to the
>> repository?  (I'm not overly concerned with configuration changes and
>> such; it's detecting checkins, tickets and other artifact changes that's
>> important).
> 
> rcvfrom might be useful:
> 
> http://www.fossil-scm.org/index.html/artifact/cae75601dd0b3940bc192ff5a8b142d099bbc4e3?txt=1=104-110
> 
> but i'm not personally familiar with it.

   That does indeed look like what I'm looking for.  Just need to check
so there aren't any corner cases.  Thanks!


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

[fossil-users] Getting time of last repository change

[Jan Danielsson]

Hello,

   Short version:  What's the best way to determine if a repository has
changed?

   I have two systems which are sync'd in a cronjob.  On one of the
systems I run a cronjob which should take action only if the repository
was changed.  Before there were two systems I simply used mtime on the
repository file; this worked well enough.  I assume, but haven't
actually checked, that the sync will cause the repository file's mtime
to change regardless of whether there were any changes imported or not.

   The most obvious method would be to do roughly what the timeline does
and find the latest modification on the timeline, but this wouldn't work
(since it would miss modifications from older checkins (say a user on a
secondary site checks in an old experimental branch)).

   Is there a timestamp for when artifacts where locally added to the
repository?  (I'm not overly concerned with configuration changes and
such; it's detecting checkins, tickets and other artifact changes that's
important).

-- 
Kind Regards,
Jan
___
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] fossil-users Digest, Vol 97, Issue 2

[Jan Danielsson]

On 02/02/16 23:19, Martin Vahi wrote:
[---]
> Thank You for the comparison. What regards to
> Your statement that "e-mail refuses to go away", then
> my answer is that the majority of the population on
> planet Earth does not consist of software developers
> or old-school communications technicians/electronics engineers
> and therefore uses the tools that the people
> at technical professions have to offer. If the
> AIM/ICQ/Vine/Google+/Buzz... was a temporary
> phenomenon and people still revert back to
> the old, unencrypted, un-anonymized e-mail, then
> the only ones to blame are the software developers,
> not the dentists, neuro-surgeon, biologists,
> mathematicians, accountants, cooks, airline service providers.

   It's not really a question of "reverting back to email", I think that
timeline illustrates that a large group of people chase what's shiny,
and don't really care if something disappears in a year or two.  For
communication which is ephemeral, that's perfectly fine, but typically
developers want things which work and will continue to do so for 20+
years; and archives are hugely important.  Random Shiny Web2.0-company
Based Communication Platform may or may not exist in two years.  Mailing
lists do not depend on a particular company existing or not.

   Back in the day when some projects moved to web based forums I was
naive enough to bookmark threads which I in my email client would have
marked as "don't delete".  Years later I noticed that plenty of these
forums had moved around (URL changes), and those links pointed to
nowhere relevant.  Important information disappearing like that is
completely unacceptable.

   Not that I don't get that there are good things about these new
platforms, but I don't see what they offer which outweighs what I lose.

   If you want developers to move away from mailing lists, invent
something which doesn't have all the drawbacks of other technologies,
but improves on the things which are important to us.  We're not afraid
of change, but we do require change to be improvement (in a pragmatic
sense).


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

[fossil-users] Recent breakage on Mac OS X

[Jan Danielsson]

Hello,

   This started happening recently:


Undefined symbols for architecture x86_64:
  "_compress", referenced from:
  _blob_compress in blob.o
  _sqlcmd_compress in sqlcmd.o
 (maybe you meant: _blob_compress2, _test_cycle_compress ,
_compress2_cmd , _compress_cmd , _blob_compress )
  "_crc32", referenced from:
  _gzip_step in gzip.o
  _zip_add_file in zip.o
  "_deflate", referenced from:
  _blob_compress2 in blob.o
  _gzip_step in gzip.o
  _zip_add_file in zip.o
  "_deflateEnd", referenced from:
  _blob_compress2 in blob.o
  _gzip_finish in gzip.o
  _zip_add_file in zip.o
  "_deflateInit2_", referenced from:
  _gzip_step in gzip.o
  _zip_add_file in zip.o
  "_deflateInit_", referenced from:
  _blob_compress2 in blob.o
  "_uncompress", referenced from:
  _blob_uncompress in blob.o
  _sqlcmd_decompress in sqlcmd.o
 (maybe you meant: _blob_uncompress, _uncompress_cmd )
  "_zlibVersion", referenced from:
  _get_version_blob in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [fossil] Error 1


   It's clearly missing a -lz somewhere.  Going back to
83b2acb7047866e43721313b7356176da6473b08 fixes the problem.

  This is my build command:
  $ cd build ; rm -rf * ; ../configure --json && make

-- 
Kind Regards,
Jan
___
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] slightly hacked Blitz skin

[Jan Danielsson]

On 21/01/16 19:17, Stephan Beal wrote:
> i recently started using the Blitz skin on all my repos, but
> fixed-/max-width pages annoy me to no end, so it go hacked every so
> slightly to remove the max width. For anyone interested, here it is:
> 
> http://fossil.wanderinghorse.net/download/skin.fossil.wanderinghorse.net

   Would the original developer of the blitz skin be okay with the
in-tree skin being updated with the width changes?

   /Jan

___
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] There is a spammer listening to this mailing list

[Jan Danielsson]

On 17/01/16 06:53, Yannick Duchêne wrote:
> I received a spam from `nella_br...@expertisetour.xyz` with subject “RE: 
> [fossil-users] What does the Older button's intended to do in the web UI?”. 
> So it appears a spammer subscribed to this mailing list, intercepts messages 
> and replies to it, which is confusing.

   I have received two of those (but from different addresses, and
replies to different mails) over the past few weeks.

   Such is life on the Internet..  :(

-- 
Kind Regards,
Jan
___
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] fossil sync doesn't sync

[Jan Danielsson]

On 09/01/16 01:15, bch wrote:
> Just talked  to Joerg off-list (who indicated that he updated fossil
> to latest on his server), and:
> 
> $ fossil pull -verily
> 
> Pull done, sent: 5064  received: 49107978  ip: 85.214.214.108
> 
> $ fossil timeline
> === 2015-05-30 ===
> 14:42:26 [0bb26b5ab6] *CURRENT* Thanks rump for not letting us use
> even mmap during initialization. (user: christos tags: trunk)
> 14:13:12 [2ece07a9d3] add HDAUDIOVERBOSE (user: jmcneill tags: trunk)
> 14:12:57 [625f16d4d3] regen (user: jmcneill tags: trunk)
> 14:12:42 [a16403f046] add Tegra124 HDMI (user: jmcneill tags: trunk)
> 14:10:01 [70b393fddb] fix path to devlist2h (user: jmcneill tags: trunk)
> 13:47:17 [3c49d42557] enable hdaudio (user: jmcneill tags: trunk)
> 
> ...
> 
> 
> still 7 months out of date.

   That's odd; my central repository has been keeping up for a long time
now (it has been working so well for the past few months that I stopped
regularly checking if it was working).

   It would be interesting to know if 16892b33c7166eb3 (the first, and
only, descendant of 0bb26b5ab6) is ever mentioned, in any form, on the wire.

-- 
Kind Regards,
Jan
___
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] Versions & manifests

[Jan Danielsson]

On 05/01/16 09:14, Steve Stefanovich wrote:
[---]
>>Is this not sufficient for your needs?  I'm not completely opposed to
>> implementing what you're asking for, but if it can already be done without
>> adding a "within a checkout" special case, I would prefer to leave it as it 
>> is.
> 
> I don't think you need such a special case. Maybe a better way is to extract
> raw tags, or provide an option to do so, because then the branch tag is easily
> distinguished:
[---]

   Ah, ok, gotcha -- I misunderstood.  I'm running low on time, but I'll
take a look.


-- 
Kind Regards,
Jan
___
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] Versions & manifests

[Jan Danielsson]

On 04/01/16 08:18, Steve Stefanovich wrote:
> Would it be too difficult to put the branch tag (i.e the tag with asterisk 
> from 'fossil br li' output) in the first line of manifest.tags?

   It probably wouldn't, but I've been trying to keep the code agnostic
with regards to being used in a checkout or not.  The "current branch
tag" is not applicable when generating archives from the web ui, for
instance.  Rather than having the build system expect the version tag to
be on the top, I'd argue it's better to use a naming convention which
makes it easily and uniquely grep:able.  (This is of course a problem if
a project/organization has an long-established naming policy which isn't
compatible with this idea).

> We use the combination of uuid and branch tag for versioning. 

   For my test-project, this is what I do in my amalgamation script:

---
uuid = ""
with open("manifest.uuid", "r") as f:
  uuid = f.readline().strip()

ver = "99.99.99"
prg = re.compile("ctlib-((\d+).(\d+).(\d+))")
with open("manifest.tags", "r") as f:
  for line in f:
res = prg.match(line)
if res:
  ver = res.group(1)
  break
---

   Generated source header:

---
/*
 * Amalgamated public ctlib interface header
 * Generated on 2016-01-04 at 16:46:45 UTC
 * Based off ctlib-0.8.1, checkout a6a61b0f239bc1f8a458a92bde37160bf6639b4f
 */
---

   In our case, there will never be a DAG node which will have more than
one release tag, so there will only ever be exactly one hit for release
versions, and zero hits otherwise.


   Is this not sufficient for your needs?  I'm not completely opposed to
implementing what you're asking for, but if it can already be done
without adding a "within a checkout" special case, I would prefer to
leave it as it is.

-- 
Kind Regards,
Jan
___
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] Versions & manifests

[Jan Danielsson]

On 01/01/16 18:43, Jan Danielsson wrote:
[---]
>Optimally the tagged version _is_ the source version. [...]

   I'm home sick, so I started working on this in the branch
jan-manifest-tags.

   I'd like some feedback on the settings semantics.  What I want to
accomplish is that any existing settings will not change any behavior.
Anyone who sets manifest to any value they are used to (0, 1, on, off,
true, false) will continue to get the same behavior as they always have.
 However I also wanted to decouple manifest and manifest.uuid from each
other when I added support for manifest.tags.  The reason for this is
simply because I use manifest.uuid, but the plain manifest I only use
for poking around in the repository (I only enable it locally and
typically only temporarily); in most cases I don't need it to be part of
tarballs and such.

   So the way it works now is that the manifest field is treated either
as before, but if it doesn't detect any of the standard booleans, it
treats the field as a sequence of flags, where 'r' means "generate raw
manifest", 'u' means "generate manifest.uuid and 't' means "generate
manufest.tags".

   I.e. to get them all:
   $ fossil set manifest rut

   To get only uuid and tags:
   $ fossil set manifest ut

   These will behave just as before:
   $ fossil set manifest on
   $ fossil set manifest false

   I gotta admit that mixing the old and the new settings semantics made
me feel uneasy, but I'm getting used to it -- which isn't necessarily a
good thing.  First impression feedback is appreciated, and if you don't
like it, suggest other possible solutions (which doesn't involve adding
another settings field).

   Also, since the three manifest settings are now essentially flags I
thought I'd make them all checkboxes in the settings web ui, but that
would require some rewiring of how the web settings interface works.

-- 
Kind Regards,
Jan
___
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] fossil sync doesn't sync

[Jan Danielsson]

On 04/01/16 02:02, Richard Hipp wrote:
> On 1/3/16, bch  wrote:
>> Indeed. I thought maybe the \n of the checkin-card (is this the right
>> characterization ?) bug/fix might fix what I've been experiencing, so
>> I updated to the latest. I'm nearly always running the tip of TRUNK.
> 
> Any idea what version Joerg is running on his server?

   Looks like http://fossil-scm.org/index.html/info/6c40678e91


-- 
Kind Regards,
Jan
___
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] Versions & manifests

[Jan Danielsson]

Hello,

   drh and sgbeal brought up the following points:

   1) Make sure an existing [managed] manifest.tags isn't overwritten.

   2) fossil add needs to be made manifest.tags-aware.

   3) Tarballs and zips need to be made manifest.tags-aware.

   4) fossil clean needs to be made manifest.tags-aware.

   5) The issue of ignore-glob needing updating on projects which use
manifests.


   Point 2 & 4 are essentially the same, IIUC; the new file is returned
as an entry in fossil_reserved_name(), which causes a lot things to Just
Work(tm).

   Point 3 is done.

   AFAICT the reserved names are implicit in ignore-glob, so I think
that's taken care of as well.  One don't need to explicitly add manifest
and manifest.uuid to ignore-glob; so the same goes for manifest.tags.

   In addition the web settings ui has been updated and the "tag"
command will update the manifests (since tags are highly relevant to
manifest.tags).

   Anything which I call "done" should be considered only very lightly
tested.  I've written a simple script to run a few automated tests, and
they yield the expected results -- but I would be surprised if there
aren't cases I haven't covered.

   AFAICT there are only a few of us here who are actually using
manifests, so I understand if people aren't jumping at the opportunity
to test this, but I attached a test-script for those who are curious and
are willing to try it out.

   The one known todo-item is point 1 in the list.


-- 
Kind Regards,
Jan


fostagtest.sh
Description: Bourne shell script
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Versions & manifests

[Jan Danielsson]

Hello,

   I have build systems which use the commit id from the manifest to
embed the commit artifact id in the binary.  I also, in most projects,
have an ordinal version number which is loosely coupled between the
repository and the build system/source in the sense that I can forget to
update the source when I tag a new version in the scm.

   Optimally the tagged version _is_ the source version.  I had a period
when I had a build system run "fossil status" and determined if there
were no changes and there was a -X.Y.Z tag, then X.Y.Z
would be used as a release version number.  However, I dislike the idea
of the build system requiring the fossil binary to build (in case
someone downloads the source in an archived form), so it never got past
a quick trial.

   (In case you're wondering, when the build system didn't detect a
"release" version it used a special (reserved) version number scheme
which we use for development builds).

   The manifest solves this issue neatly for the commit id; but can it
be made to solve it for version numbers with ordinality?

   How feasible would it be for fossil to in addition to manifest and
manifest.uuid write something like manifest.tags which is simply a file
which lists all (current) tags (newline-separated)?  Build scripts could
grep -X.Y.Z to determine the release version.  It would
also allow build systems to use scm tags to flag certain other
attributes; imagine an "experimental" tag, for instance.  (For those who
haven't used manifests: The neat thing with them is that they are a part
of generated source archives).

   It would also allow tagged version numbers to easily be put into
amalgamated sources, for those of us who like to include amalgamation
scripts with libraries.

   Settings-wise, I wouldn't want to add a new option for this, but
perhaps the "manifest" setting can grow from a simple boolean to
something along the line of a "off, on, full" setting.  The idea would
be to make the change completely non-intrusive and completely invisible
to users who have no need for it.

   Thoughts?

   Regarding feasibility; the question isn't whether it *can* be done,
the question is whether the queries are too costly to be able to keep
the "manifest.tags" updated when required.

-- 
Kind Regards,
Jan
___
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] xkcd on git

[Jan Danielsson]

On 03/11/15 00:38, Scott Robison wrote:
>>> On 11/2/15, Jan Danielsson <jan.m.daniels...@gmail.com> wrote:
>>>>
>>>>   Supporting symlinks on Windows would currently be a little mess.
>>>
>>> What if we just say that symlinks don't work on Windows and that if
>>> you include them in your repo, you won't be able to checkout (sanely)
>>> on Windows?
>>
>> I think Fossil should give a best-effort try via UAC, but yeah, if that
>> doesn’t work, no tears should be shed about it.
>>
> 
> I know I've posted this before, but just to reiterate:
> 
> If you are an unprivileged user, you can create symlinks if you've been
> granted the symlink priv. It is not hard to do at all.

   Sure, but that means instructing people to change a system policy to
be able to check out code in repositories which use symlinks.

   Unless we pop up a question "Do you want to reconfigure the system to
allow symlinks?" if needed, that would be more acceptable to me, but how
do we handle domain environments where GPO's are pushed out by the
domain controller, and the user can't change that setting?

> The problem comes with UAC for unelevated administrative users only,
> because Microsoft in their infinite wisdom saw fit to strip symlink privs
> from unelevated admin users by default.

   Agreed.

> One: Most windows users wouldn't be using symlinks and wouldn't care.

   Agreed, again.

> Two: It's not hard to have two command prompts open, one running as a non
> admin user with symlink privs. One could run fossil from the non admin
> user. Or one could easily run fossil as the non admin user that has symlink
> privs.

   This may surprise some of you, but I can point to a large IT
consultant firm with thousands of developers world-wide who do _not_
have administrator privileges on their own systems.  They simply can't
open elevated command line prompts, unless they are driver developers
who have been given special privileges due to specific project requirement.

   I agree it's a theoretical point in this specific discussion, but
just reminding that being able to open up an elevated command prompt can
actually be a luxury in some environments, so it's not a "catch all"
solution in Windows.

> Maybe it's not worth doing, and maybe I shouldn't have bothered adding real
> symlink support in the winsymlink branch. However, it is possible, and it's
> not as onerous as many people are making it out to be.

   My skepticism boils down to the fact that we can't make a general
solution which will work smoothly everywhere[*].  Call it OCD if you
will, but I think "We support symlinks on Windows, but not without
policy changes to the system and not in these types of special
environments." looks a little iffy, considering there are no such
caveats on other platforms.

   That said, like I said earlier, I don't object to anyone willing to
give it a shot, and seeing as you already have done it, then there's no
sense in me making the argument that it would be better to wait until
symlinks on Windows are more polished.

   I am curious to know though how you get the reparse point, and if
you've encountered those hangs.  I didn't know about the winsymlink
branch, so I'll take a look.


   [*] In practical terms, as you say, more or less zero users (today)
will encounter these problems.  As stated; to me it's more the asymmetry
which bothers me.

-- 
Kind Regards,
Jan
___
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] xkcd on git

[Jan Danielsson]

On 03/11/15 00:00, Warren Young wrote:
> On Nov 2, 2015, at 3:56 PM, Richard Hipp <d...@sqlite.org> wrote:
>>
>> On 11/2/15, Jan Danielsson <jan.m.daniels...@gmail.com> wrote:
>>>
>>>   Supporting symlinks on Windows would currently be a little mess.
>>
>> What if we just say that symlinks don't work on Windows and that if
>> you include them in your repo, you won't be able to checkout (sanely)
>> on Windows?
> 
> I think Fossil should give a best-effort try via UAC, but yeah, if that 
> doesn’t work, no tears should be shed about it.

   Personally I don't think UAC is a viable solution.  Just imagine
having typed "fossil update" as an unprivileged user and it suddenly
says "Hey, I can see you want to perform potentially dangerous
administrative tasks -- are you sure you accept?".  I really don't think
it's reasonable for an unattended user to have to switch to
administrator mode for checking out/updating code.

   I don't know which is worse; not supporting symlinks at all on
Windows, or telling people that they need to have administrator
privileges on their system in order to check the code out (note: not
build, just to check the code out).

   Also; if anyone has automated/unattended build systems on Windows for
projects which have symlinks -- those checkouts/updates won't be able to
be unattended any longer, unless they want to change the build system to
run as administrator (which I would guess is a huge no-no in most cases).

   Like I wrote earlier, I think the symlink situation on Windows is too
messy currently.  I won't oppose anyone who gives the UAC route a shot,
but I think the feature will be way too flimsy on Windows -- it won't
look good, and I'd wager people who encounter these issues will blame
fossil for it.

   I think it's best to say Windows doesn't support symlinks for
unprivileged users, and fossil requires basic day-to-day operations to
work for unprivileged users, so it won't support symlinks on Windows
until they improve.

   With all that said -- I have no idea if things have changed to the
better on that front in Windows 10.

-- 
Kind Regards,
Jan
___
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] xkcd on git

[Jan Danielsson]

On 02/11/15 23:23, Warren Young wrote:
>> Windows will ultimately get decent symlink support.
> 
> I doubt it.  Microsoft has tried to take a bite of that apple twice, and 
> screwed it up both times.
> 
> First there was the Windows 95 *.lnk file feature, which is basically only a 
> symlink to Windows Explorer.
> 
> Then in Vista they finally added true symlinks, but only Admin users can 
> create them, and then only from within an Admin shell!  cmd.exe doesn’t know 
> how to temporarily auto-elevate itself via UAC, as with most other privileged 
> operations.  (There’s no reason that Windows builds of Fossil can’t do the 
> UAC dance, though.)

   There may be Reasons that only admins can do symlinks.  If you read
about reparse-points in the DDK you start to get the sense that it was
hooked on to another set of functions as a "Oh, look, we kind of get
this feature for free, but with some caveats".

   The Community could work around the problem by creating a service
which is responsible for creating the appropriate reparse-point, and
allow regular users to communicate with the service.  There's another
reason I think symlinks are limited to administrators for now, but it's
out of scope here.

   Anywho, back to more fossil-related matters..  I've tried to work in
support for handling (reading/parsing) Windows symlinks in a library,
and I encountered an interesting problem when attempting to do what
would be considered readlink() in unix -- the call sometimes hangs(!).
For seemingly no good reason.  A quick search yielded that I'm not the
only one seeing the problem; and last time I checked there had been no
activity from Microsoft regarding a fix.

   The work-around is to use the DDK and manually parse the reparse
point data manually (which is how I ended up browsing through the
reparse point parts of the DDK..).

   Supporting symlinks on Windows would currently be a little mess.  Not
only is it the admin-issue, but unless they fix that intermittent hang
bug, we'll require parts of the DDK and do some ugly low-level parsing
in order to parse the links.

-- 
Kind Regards,
Jan
___
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] Fossil server

[Jan Danielsson]

On 01/11/15 13:30, Damien Sykes-Pendleton wrote:
> I’m running Windows. I’m not personally running anything on port 80, though I 
> get a blank web page (as opposed to a 404 or problem loading error) when I 
> visit localhost.

   I forget the name of the tool, but in there's a nifty tool for
Windows which can list all the ports and which process owns them.  I
think the tool is part of the Sysinternals Suite (a quick glance makes
me think it may be "PortMon", but I'm not sure).  If you can't figure it
out any other way, you could use that to find out who is hogging port 80.

-- 
Kind Regards,
Jan
___
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] xkcd on git

[Jan Danielsson]

On 31/10/15 06:27, Michal Suchanek wrote:
[---]
>> (For instance, my recent thread about how to clip off a a branch via the 
>> command line when the UI can’t do it because it was created empty, something 
>> Fossil can’t do, but which apparently CVS or SVN can, so it got into my 
>> Fossil tree when I converted.)
>>
>> This as compared to the sentiment in the XKCD comment, where if Git screws 
>> up, it’s often simpler to just toss the checkout and start over than try to 
>> recover.
> 
> Seriously, how do you screw up like this with git?
> 
> Unless you delete .git your checkout is always in well defined state.

   No.  I had a checkout of a repository which was working fine.  One
day I suddenly couldn't do things I have been doing all along with it
(uncomplicated daily tasks; pull, commit, merge); git told me that my
repository was broken.  I googled for the error, found a stackexchange
question about the error message and a few of the replies where along
the line of "Yeah, that randomly happens sometimes, just type these
commands and it'll fix it." (no explanation, just "the word on the
street is that these commands help").  I copy-n-pasted the commands, git
did some work on the repository and it fixed the problem (as far as I
could tell).

   To your point though: Those who replied seemed to think this was
normal, so I guess one could argue that error is a "well defined state".

   I was about to just delete my checkout and start again, but I was
curious to see if anyone else had encountered it.

-- 
Kind Regards,
Jan
___
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] Self Signed Certificates

[Jan Danielsson]

On 16/08/15 19:56, Saul Hazledine wrote:
 Hello,
   I have been using a self-signed certificate on my Fossil server for
 the last year and it just expired. I have replaced the expired
 self-signed certificate with a new/different self-signed certificate.

   I assume you aren't using client certificates; but I'll ask anyway:
Are you using client-certificates to achieve mutual authentication, or
is it a server-only certificate?

 However, two scary things happened:
 1. The Fossil client kept on working with the old expired certificate.

   We could check for expired certificates on the client, but note that
the important question is whether the server accepts expired
certificates.  (The client can be manipulated, so that check can't be
trusted for access control).

   What are you using to serve the repository over SSL?  stunnel?
Apache?  Other?

   It was a while back, but I have a vague memory of fossil complaining
when my certificates expired; though I use mutual authentication -- and
I'm not entirely sure I remember correctly.

 2. Fossil trusted the new certificate without any interaction from me.

   Did you point out the new CA certificate on the client?  If you did,
then you got the expected behavior; when you point out a CA certificate
you're telling fossil that you trust it as an signatory for certificates
(hence you trust the server/client certificates which it has signed).
(This is in fact the whole point with X.509 PKI, and where it differs
from structures like OpenPGP).

   If you didn't add the CA as a trusted CA in fossil, then it should
have asked you to trust the server certificate.  I'm not sure how the
check is done; if it only compares name fields it's not good.
Unfortunately I'll be a little busy the next few days, but send me a
ping in a week or so if it still remains a mystery and I'll take a
closer look.

 Have I done something stupid or have I misunderstood what protection
 Fossil provides when using self signed certificates?

   There's no technical difference between self-signed certificates and
commercially signed certificates, so (in this regard) they should work
the same.

-- 
Kind Regards,
Jan
___
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] Any interest in testing/merging check-in-edit branch?

[Jan Danielsson]

On 18/07/15 17:09, Scott Robison wrote:
 Still on phone. Instead of -euser how about -author? Instinctively seems
 less clumsy but it's just a knee-jerk reaction to -euser which seems both
 long and short simultaneously. :)

   I agree x 2.

-- 
Kind Regards,
Jan
___
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] SQLITE_BUSY ?

[Jan Danielsson]

On 17/06/15 11:38, Joerg Sonnenberger wrote:
[---]
 Sadly, a plain pull is not 100% read-only, so WAL doesn't help avoiding
 such problems.

   Out of curiosity; why aren't pulls 100% read-only on the server?

-- 
Kind Regards,
Jan
___
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] NOT_A_FILE problem

[Jan Danielsson]

On 05/06/15 13:08, jim Schimpf wrote:
[---]
 EDITED Docs/HayJam.pdf
 NOT_A_FILE Docs/images/Detector.graffle
 EDITED Docs/images/Detector.png
 
 So I then did a fossil rm of this file and did an OS rm and removed if from 
 the directory.
 
 put it back in the directory and fossil added it to the repository again.
 
 Trying commit again I got the same problem. The status shows it’s added as a 
 directory so I don’t see why this failed

   I've always thought of the changes within a commit not to be seen as
an ordered journal (i.e. first do this, and then do that), but rather
that it should be seen as all events occurring at the same time (or in
an undefined order).  I always make sure there aren't any
contradictions in a commit (i.e. remove file X, and X is also a
directory in the same commit).

   I assume that if you commit between removing the file, and then
adding the directory, that it'll work (I'm pretty sure I have done that
in the past?).  Did you try that?

-- 
Kind Regards,
Jan
___
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] trunk closed??

[Jan Danielsson]

On 29/05/15 22:15, Matt Welland wrote:
 We emphatically do NOT want Fossil second-guessing what branch you
 want to be on when you do fossil update without an argument.
 
 Whatever option you decide - either way you are second guessing the users
 intent.
 
 1. Current behavior is really, really confusing.
 2. You *were* on trunk but magically ended up on some other branch.
 3. It has caused real-world wasted time for me and for others that I
 support.

   For my part I don't think the current behavior is confusing, but
thinking outside of my own little box it's difficult to disagree with
you.  I don't think any of the developers I have introduced fossil to
really care about learning about even the most superficial internals of
it, and I'm willing to bet that if they encounter this particular
situation they would call me and first ask me why fossil is broken, and
once I have explained to them that it isn't they'd ask me how they can
make it not do that any more.

   That said, Richard is right about that it can get complicated when
guessing where the user expects to be, but it shouldn't be difficult to
warn about were the user was, and now is, after an update.

-- 
Kind Regards,
Jan
___
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] New skin: Blitz

[Jan Danielsson]

On 13/03/15 19:11, James Moger wrote:
[---]
 Blitz has two variants (with logo  without logo).  It includes an
 alternative Ticket page layout and several image resources which may be of
 use to other skins.

   Would you be willing to change the upper-case 'A-F' in hex digits to
lower-case in the timeline?

-- 
Kind Regards,
Jan
___
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] Google code shutting down

[Jan Danielsson]

On 13/03/15 20:55, Richard Hipp wrote:
 Few organizations have the problem that the full power of Git solves.
 And yet many organizations voluntarily take on the problems that come
 with using Git.  Weird.

   One shouldn't underestimate the power of because everyone else does it.

-- 
Kind Regards,
Jan
___
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] New skin: Blitz

[Jan Danielsson]

On 13/03/15 19:11, James Moger wrote:
 Hello Fossil community,
[---]

   This just became my new favorite skin.  Thank you for submitting this.

-- 
Kind Regards,
Jan
___
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] RFC regarding short UUID for some command line use.

[Jan Danielsson]

On 08/03/15 06:48, Andy Bradford wrote:
 There  have  recently  been  some  changes  to  make  short  UUIDs  more
 prominent, however, I  think that new checkins should  still display the
 full UUID:
[---]
 Thoughts?

   None other than a simple I agree.

   /Jan


___
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] Justification for two-step mv and rm

[Jan Danielsson]

On 06/03/15 15:10, Jan Nijtmans wrote:
[---]
 fossil rename already exists as alias to fossil mv, so I
 suggest to add fossil forget as alias to fossil rm. Then
 later the behavior of fossil rm/mv can be modified, while
 forget/rename will continue to behave as rm/mv do now.
 
 Any objections against adding fossil forget as alias
 to fossil rm  If not, I'll be glad to add it, awaiting
 further discussion.

   No objection.  I'm even going to go so far as to say I'll be cheering
you on.

   /Jan

___
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] Old problem not entirely gone?

[Jan Danielsson]

On 02/02/15 23:23, Warren Young wrote:
   The annoying thing is that when it fails, it wipes away whatever
 progress it has made.
 Yes, well, that’s the nature of transactional DB updates: all or nothing.

   Implied: There's only one way to use transactions when performing
initial synchronizations.

 How difficult would it be to allow fossil to pick up where it left
 off in such a case? 
 Are you seriously asking for Fossil to allow a local clone to be in an 
 inconsistent state after an error?

   I'm working on a distributed storage system which borrows a few of
the basic ideas from fossil (immutable artifacts, etc).  We perform a DB
commit after an entire *application layer* transactional unit has been
transferred.  When an initial synchronization breaks in our system, we
use a simple method to skip artifacts when it resumes; we divide the
timeline into week-long chunks, and hash all the artifact hashes in
order of time in each chunk; once a week is encountered where the hashes
don't match, we perform a fine-grained sync of the artifacts for that
week.  We deal with up to GB-size artifacts (indexed in DB, but not
stored there), and the entire data storage can be in the region of
terabytes.  The system runs over the regular Internet.  It must be
tolerant to faults like pull network cable, or ISP hiccups, because
restarting from scratch after 90% has been synchronized simply isn't an
option.

   In terms of the type of data, our data and fossil's data is very
different, but in terms of the time it takes to synchronize large data
stores/repositories, we're in the exact same situation.  We don't expect
synchronizations to fail; they rarely will, but it will happen sooner or
later, so we were forced to find a way to skip work that has already
been done.

   We don't remove all the work which has been done after a failed
initial synchronization.  Nor do we leave it in an inconsistent state
-- we leave it in an incomplete/resumable state, and it's clearly
tagged as such.  I'm not even asking if fossil could be made fully
resumable after an exit either, a An error was detected; retry [y/n]?
would be another option.  If it's impossible for fossil to do anything
like that without major rewiring of the internals, then *that* would be
relevant to my question.

   So to answer your question: No.  Not that I ever implied anything of
the sort.

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

[fossil-users] Old problem not entirely gone?

[Jan Danielsson]

Hello,

   I used to have major difficulties cloning huge repositories.  (See
http://lists.fossil-scm.org:8080/pipermail/fossil-users/2014-May/016234.html).

   In that thread the commit
http://www.fossil-scm.org/index.html/info/b4dffdac5e706980d911a0e672526ad461ec0640
was brought up as a potential fix.  I updated to get the fix and then
tried running a clone, and I could indeed get the entire repository.

   Since then I have discovered that the fix only makes the problem much
less likely to happen; I have successfully cloned the netbsd repository
a few times, but on the odd occasion I still get:

--
Round-trips: 662   Artifacts sent: 0  received: 1970955
Error: Database error: database is locked: {UPDATE event SET
mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT
mid FROM time_fudge);}
Round-trips: 662   Artifacts sent: 0  received: 1970955
Clone done, sent: 162233  received: 3871283762  ip: X.X.X.X
server returned an error - clone aborted
--

   The annoying thing is that when it fails, it wipes away whatever
progress it has made.

   How difficult would it be to allow fossil to pick up where it left
off in such a case?  Obviously The Real Fix(tm) is making sure the
database error doesn't occur, but I can think of other situations
(someone accidentally unplugged a network cable, etc) where one wouldn't
want it to delete the progress it has made already.


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

[fossil-users] Breaking out of fossil ui leaves files

[Jan Danielsson]

Hello,

   I just noticed something which I can't recall seeing before.  I
started fossil ui on a repository (-R foo.fossil), and when I hit
ctrl-c, it terminated as expected, but it left the corresponding -shm
and -wal files.  I'm pretty sure I have used fossil ui on wal'd fossil
repository databases before, but don't recall having to delete these
files after stopping fossil ui.

   This coincides with having upgraded the OS my Mac, so there's that
factor as well.

   Has there been any recent changes which might explain this, has it
actually always been this way, or is it an OS behavioral change thing?

   A quick grep through the source leads me to believe that there is no
registered signal handler to handle SIGINT apart from when an sqlite
shell is started.  Which leaves me slightly surprised that I haven't
seen those files laying around before.

-- 
Kind Regards,
Jan
___
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] Breaking out of fossil ui leaves files

[Jan Danielsson]

On 17/10/14 20:01, Jan Danielsson wrote:
[.. -wal  -shm remain after ctrl-c:ing out of fossil ui ..]
A quick grep through the source leads me to believe that there is no
 registered signal handler to handle SIGINT apart from when an sqlite
 shell is started.  Which leaves me slightly surprised that I haven't
 seen those files laying around before.

   ...but there is an atexit() which calls db_close().  Are the
semantics regarding SIGINT vs. atexit() well-defined?

-- 
Kind Regards,
Jan
___
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] Horror story about git - Forever Alone

[Jan Danielsson]

On 25/09/14 13:18, Matt Wellans wrote:
 I suspect fossil would slow down faster than git in that scenario but I'd 
 also argue that because fossil is easier to understand that scenario is a 
 little less likely to happen.

   Let's all be honest here; this a unique case where you'd _want_ it to
slow down faster than git.  The tool shouldn't encourage misuse.  If the
story is true, they might have noticed the problem sooner.  :)

   Half kidding, of course.  Performance is always good, etc.

-- 
Kind Regards,
Jan
___
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] SSL issue on Mac OS/X?

[Jan Danielsson]

On 12/06/14 18:06, Ron Aaron wrote:
 OK, my second fossil question in one day:
 
 I recently moved my repo from standard http to https (behind Apache)
 
 My linux machines had no problem with the change over.
 
 But the OS/X machine cannot connect to my repo.  I get:
 
 SSL: cannot connect to host ...:443 ()
 Pull finished with 0 bytes sent, 0 bytes received
 
 I can ping the host from the Mac, and I can also openssl client to it.
 
 I don't know if this is a Mac or a fossil problem... any ideas?

   I use fossil on Mac OS X (client) against a NetBSD server running
apache 2.2 (recently upgraded to 2.4), with full client certificate
validation, and have been doing so for well over a year.  Used to be
running 10.8 and am now running 10.9.  Apart from one or two isolated
glitches, I've never had any problem.

   It should definitely work.

   The fact that it can't even connect feels a little strange..  Are you
using a proxy?

-- 
Kind Regards,
Jan
___
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] SSL issue on Mac OS/X?

[Jan Danielsson]

On 12/06/14 20:29, Ron Aaron wrote:
 Nope, no proxy.  And I can connect from my linux clients just fine.
 
 I tend to think it's related to the certificates.

   openssl in Mac OS X is very old, so if you're using EC, RSA/PSS or
something of the sort it could be an issue.


-- 
Kind Regards,
Jan
___
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] can fossil try harder on sync failure?

[Jan Danielsson]

On 02/05/14 19:57, Andy Bradford wrote:
 Artifacts sent: 0 received: 895 Error: Database error: database is locked:
 {UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE
 objid IN (SELECT mid FROM time_fudge);} #key_3_2
[...]
As you say, it is highly  reproducible, but it requires quite a bit
 of time to trigger sometimes.
 
 This particular  error hasn't come  up since this checkin  (which didn't
 make it into Fossil 1.28, so it's only in trunk or on branch-1.28):
 
 http://www.fossil-scm.org/index.html/info/b4dffdac5e706980d911a0e672526ad461ec0640
 
 I wonder if you could try again with a build from trunk?

   I've been using later versions of fossil for both the NetBSD and
pkgsrc repositories since this discussion took place, and I had one
{COMMIT} error, but other than that it has worked great.  I'm so happy
to be able to nuke the git repositories I have been using as a work-around.

   I'm very, very happy about this fix -- it changes a lot for me
(exclusively to the better).

-- 
Kind Regards,
Jan
___
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] Fossil process hanging on sync to remote server?

[Jan Danielsson]

On 10/05/14 10:53, Gerald Gutierrez wrote:
[---]
 pContent=unavailable, N=unavailable) + 50 at http_ssl.c:399
396   size_t got;
397   size_t total = 0;
398   while( N0 ){
 - 399 got = BIO_read(iBio, pContent, N);
400 if( got=0 ) break;
401 total += got;
402 N -= got;
 
 So, it's hanging in the BIO_read function.

   ...which is probably blocking and waiting for data.  Either it's
supposed to wait for data which the other side isn't sending (a problem
at the other side?), or it has gotten the idea that it needs more data
even though it doesn't (a local problem?).  I'd start by taking a look
at what the other side is doing.

   Is it possible for you to test without SSL?

-- 
Kind Regards,
Jan
___
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] can fossil try harder on sync failure?

[Jan Danielsson]

On 18/04/14 17:52, Matt Welland wrote:
 Just FYI, I'm seeing this kind of message quite often. This is due to
 overlapping clone operations on large fossils on relatively slow disk.
[---]
 Artifacts sent: 0 received: 895 Error: Database error: database is locked:
 {UPDATE event SET mtime=(SELECT m1 FROM time_fudge WHERE mid=objid) WHERE
 objid IN (SELECT mid FROM time_fudge);} #key_3_2

   That error is the reason I had to switch over to the git port of the
netbsd fossil repository.  First I thought it was a
fossil-on-bsd-problem, but I got it on Linux as well.

   As you say, it is highly reproducible, but it requires quite a bit of
time to trigger sometimes.

   I'm not running on NFS, but I get the exact same behavior.

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

[fossil-users] https-over-proxy

[Jan Danielsson]

Hello,

   I did some work to get https-over-proxy working because both a friend
and I both needed it, and there was a ticket requesting the feature.

   Now the place where my friend works no longer uses proxies for
outgoing traffic, so he no longer needs it, and I very rarely use it.

   So, the question is: Merge to trunk, or let it bitrot? I get the
feeling that http proxies for outgoing connections is going away, making
this feature slightly esoteric. Am I wrong? Is anyone using it?

   /Jan
___
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] https proxy tunnel

[Jan Danielsson]

On 28/10/13 13:39, Jan Nijtmans wrote:
[---]
 Conclusion: your branch works fine as long as the password is
 not taken from the (https) url.
 
 I hope this feedback is useful to you.

   Yes, very useful. We only use client certificates, and apache is set
up to set REMOTE_USER from the client certificate, and fossil uses
REMOTE_USER without authentication -- so the case where user passes
password via the url is one which I had missed completely. I'll fix as
this weekend or so. Thanks for trying/reporting!

   /Jan

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

[fossil-users] https proxy tunnel

[Jan Danielsson]

Hello,

   The jan-httpsproxytunnel branch has been tested on NetBSD, Mac OS X,
Linux and Windows against three different proxies, at two very different
environments, and it is working well.

   Feedback from people more accustomed to the world of http proxies
would be appreciated.

   /Jan
___
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] http-proxy + https

[Jan Danielsson]

Hello,

   There's a jan-httpsproxytunnel (work-in-progress) branch with support
for tunneling https over a http proxy.

   I have done a few https-over-http-proxy clones, and I also made some
https (without proxy) clones to see if I broke anything. I have however
not done extensive testing, so .. please try and report if something
which worked previously no longer does.

   I'd like to clean up the global variables context with regards to the
proxy support. Some variable names are slightly misleading, and I think
some of them would do well living in a separate namespace.

-- 
Kind regards,
Jan Danielsson




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

Re: [fossil-users] Control artifact types [Was: Minor new feature: comments when closing/re-opening]

[Jan Danielsson]

On 08/23/13 18:10, Stephan Beal wrote:
 THANK YOU Mark - i wasn't paying attention. Jan, i'll send you the NEW
 password off-list.

   For a short moment there I thought This has to be the most trusting
community EVER!. :)

-- 
Kind regards,
Jan Danielsson

___
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] How to ignore UNIX executables?

[Jan Danielsson]

On 8/15/13 3:23 PM, John Long wrote:
 Hi, is it possible to ignore UNIX executables? I want to do an addr on a
 directory tree but I don't know how to tell fossil not to track the binaries
 since they have no naming pattern. Until now I've been living with it but it
 is very annoying and time for me to ask. Help!

   It's Unix; try to learn using the tools at your disposal. I used to
hate when people told me that, because I thought figuring out the syntax
for all the commands took too long, but the trick is not to try to do it
in a neat way, but rather just get it done.

   $ find . -type f | while read line; do if ! [ -x $line ]; then fossil
add $line ; fi ; done

   .. or, if you want to put it in a script for reuse ..

   #!/bin/sh
   find . -type f | while read line
   do
 if ! [ -x $line ]
 then
   fossil add $line
 fi
   done

   .. and you could add a if ! [ x$line = x.flsckout ] test as
well, if you need to run it from the root.

   /Jan

___
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] self-hosted Fossil for a team

[Jan Danielsson]

On 8/11/13 2:07 AM, Chad Perrin wrote:
 So . . . let's say I have a server (running FreeBSD, and I'll probably
 be setting this up in a jail) and a router that can forward ports
 (already has SSH forwarded to this server).  For argument's sake, let's
 say we're confined to only one port per protocol.  What's the quick/easy
 way to get Fossil set up so a small team can push/pull/sync multiple
 Fossil repositories on the server without having shell accounts?  The
 connection should be encrypted so that nobody can sniff usernames and
 passwords when people are syncing, the users should preferably all be
 using different credentials (not the same username/password combination,
 in other words), and I should not have to pay any money to any third
 parties (ISPs, certifying authorities, et cetera) as part of this.

   I have been using a combination of self-signed certificates, apache
and fossil for a long time and have been very happy with it. (Apache is
configured to only allow connections with full certificate chain
verification).

   apache is configured to set REMOTE_USER to the CN-field of the
certificate's subject, and the fossil repository is configured to get
username from REMOTE_USER. So the only thing the users need to do is to
place the CA, their certificate and key in a Good Place, and then set up
fossil to use them. If the users will be accessing the web ui via a
web-browser they will need to make the appropriate configurations to
their web browsers as well.

   The users don't have to enter a password other than to unlock their
local private key. (As a matter of policy; if they have the key on
encrypted partitions they don't even have to do that).

   I use apache's access management tools to configure which
users/groups can access which repositories.

   The only part of the whole configuration which I found to be annoying
was the generation of certificates/keys (the openssl command line tool
and online manual is at times very unfriendly). Other than that, it was
pretty much a breeze.

   If this is something you're interested in, then I can post more
detailed instructions on how to set it up.

   /Jan

___
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] Fossil on cygwin64

[Jan Danielsson]

On 7/25/13 2:05 PM, Lluís Batlle i Rossell wrote:
[---]
 grep tells me that there are 33 instances of the __CYGWIN__ macro in
 Fossil, in 8 different files.  So if you use sed to change them all to
 __CYGWIN_OFF_ (or something else harmless) and then do ./configure; make,
 does it work?   (I don't have cygwin installed so this is not something I
 can easily test.)

 If it does work, then I move for the immediate banishment of all __CYGWIN__
 macros.
 
 fossil clone in cygwin64 now works perfectly:

   So .. we used the __CYGWIN__ macro to explicitly break fossil on
cygwin? That seems unnecessarily creative to me.

   Out of curiosity (there must be one or two here who put them there):
What are/were their intended purposes [in the fossil code]?

   /Jan

___
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] Fossil on cygwin64

[Jan Danielsson]

On 7/25/13 2:10 PM, Richard Hipp wrote:
 Move to banish __CYGWIN__ from both Fossil and SQLite sources.  Do I have a
 second?

   Seconded.

   /Jan

___
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] Side-by-side diff improvement

[Jan Danielsson]

On 07/06/13 04:51, Joel Bruick wrote:
[---]
 The purpose of this commit is, as the commit message says, to support
 arbitrary line lengths with synced horizontal scrolling in side-by-side
 diffs. Here's an example of it in action on a test copy of the Fossil
 repo:
 http://joelface.com/fossil/fdiff?v1=98aec3c55155011bv2=d74d0c320c455abdsbs=1(you
 can click anywhere inside a diff and use the left/right arrow keys to
 scroll)

   I instantly can't live without it.

-- 
Kind regards,
Jan Danielsson




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

Re: [fossil-users] Did you know that Fossil could do...

[Jan Danielsson]

On 5/28/13 3:08 PM, Richard Hipp wrote:
 Survey:  How many people know that in the web-based timeline for Fossil,
 you can click on any two nodes in the graph and get a diff between those
 two nodes?

   I knew about it. When I read the first paragraph I was afraid you
were about to suggest removing the feature for some reason, which would
have made me very unhappy since I use the feature frequently (one of
those can't live without it features).

 I think this is a very useful feature.  But I'm guessing that not many
 people know it exists.  Please confirm or refute my guess.
 
 And assuming I'm guessing correctly, do you have any suggestions on how I
 can get the word out about this and other useful but obscure features of
 Fossil?

   Perhaps an Introduction to Fossil document -- complete with
pictures illustrating how to use it?

   Have you seen The NetBSD Guide? Those types of documents are
invaluable to get to know systems, imho. Fossil wouldn't need one quite
that big, but a guide with topic along the line of Branching,
Merging, Using the timeline, etc chapters would be helpful to get
people started with fossil and learn about useful features.

   /Jan
___
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] Fossil 1.25

[Jan Danielsson]

On 01/18/13 20:09, sky5w...@gmail.com wrote:
 1. Visual Studio is not in my PATH, but the following cmd seems to
 have tried and failed?

   Don't start a normal cmd.exe; start the Start Visual Studio Command
Line (don't remember the exact title, but you'll find it easily if you
look for it), which should be somewhere in your Start-menu (under the
Visual Studio folder).

   It'll set up the environment, and you'll be able to build fossil.

-- 
Kind regards,
Jan Danielsson




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

Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?

[Jan Danielsson]

On 12/31/12 11:17, Nico Williams wrote:
[---]
 But I feel I must at least address this
 insinuation that I was trolling.

   It's obvious that you aren't trolling. You don't have to defend
yourself against such nonsense.

-- 
Kind regards,
Jan Danielsson

___
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] Fossil vs. Git/Mercurial/etc.?

[Jan Danielsson]

On 12/31/12 19:52, Doug Currie wrote:
 On Dec 31, 2012, at 1:29 PM, Nico Williams n...@cryptonector.com wrote:
 I haven't yet re-unsubscribed.  Joerg's note added hope 
 Thank you for explaining rebase. It's not something I've ever needed to do, 
 so I was skeptical of its value, and even more skeptical that it would ever 
 be adopted by Fossil. While you have not converted me to an advocate, I've 
 learned why you find it useful, and how it may be achieved without destroying 
 history. I thank you for that, and for trying to be constructive and civil on 
 this mailing list. 

   I wholeheartedly agree (with the entire paragraph).

   I have never used rebase, nor do I see any use for it in my daily
work-flow. That being said, I've thought that about many things in the
past until it was suddenly available to me. (And history is full of such
examples for others as well. (3D acceleration? Linux users used to be
quick to point out that only 1ame g4m3rz and n00bs need it [because it
wasn't available on Linux]. Nowadays some Linux desktops even require 3D
acceleration to run normally)).

   But more importantly, I don't see my current own personal lack of
interest for rebase as a barrier to having the feature in fossil. As
long as it doesn't break the DAG I'm fine (and Nico was clear about that
being the intention). Things makes fossil more appealing and could help
transition users to it from other systems is good in my book.

   Nico and Joerg have made it clear to me, as a rebase n00b, that
there's a very fossil way to have rebase. And if I read Michal Suchanek
correctly, we could even do it better than the arch-typical example of
rebase (git).


   ..and I hope Nico's constructive and civil tone will be an
inspiration to the community going forward.

-- 
Kind regards,
Jan Danielsson

___
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] Fossil vs. Git/Mercurial/etc.?

[Jan Danielsson]

On 12/19/12 22:57, Remigiusz Modrzejewski wrote:
 It stands in stark contrast to Fossil's everybody has a copy of 
 everything.

 Except for private branches. There's been some discussion about adding
 more control over push/pull to fossil, but I don't believe it's
 happened yet.
 
 Private branches are a pretty recent addition. I believe that the fine 
 grained pushing/pulling will also come sooner or later, once one of folks 
 involved with Fossil feels a need for it.

   Oh, there's definitely a need for it. Like I have mentioned several
times before; the full NetBSD fossil repository is unusable for regular
source management work. If one could check out individual branches, then
perhaps it would become usable (though that's pure speculation at this
point).

   A while back I did some preliminary work to see how one would
implement branch-specific pulls, but before moving along with it I
(obviously) asked on the mailing-list to see if anyone else was working
on it. And at the time, someone was. And last I heard, there had been
some significant progress done, but with a few issues to be resolved.

   Unfortunately, I haven't seen anything on this for quite a while now,
so I get a feeling it was abandoned. And currently I don't have the time
to pick it up myself.

   ..the proper solution would be to look into the scalability issues
without looking into limited clones -- but there's also a point in
limiting the size of the transfer, so the limited clone feels like a
better first try project, since it *definitely* solves one issue, and
_may_ solve another one.

-- 
Kind regards,
Jan Danielsson

___
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] Fossil vs. Git/Mercurial/etc.?

[Jan Danielsson]

On 12/18/12 22:29, Mike Meyer wrote:
[---]
 I don't know of anyone using it for a large team. I don't know of any
 reason not to, except for the risk of being the first to try that.

   I don't think large team is a problem, apart from the manual work
required in setting up users. I did some work a while back gluing
together fossil with a security middleware which has an integrated
identity manager. It reused the identity manager to configure fossil
server instances. I did some quick'n'dirty hacks; like opening up the
repository via libsqlite and manipulated the databases directly, which
didn't feel all too excellent. (Though the whole thing was a
proof-of-concept and something to demo, more than anything else).

   My primary experience from that project was that there are some areas
where fossil could be enhanced to allow easier integration with identity
managers, which could ease user-management for very large teams.


   The biggest problem I have encountered with fossil is with regards to
scalability. Anyone who has tried to use the NetBSD fossil repository
knows it's a pretty painful experience.

   With that said, I came to fossil from bazaar which I abandoned
because it had scalability issues (which were even worse), so it's not
an exclusive fossil-problem. (git isn't affected by this though, but
it's noteworthy that the NetBSD project on github is (was?) imported
from the fossil NetBSD repository).

-- 
Kind regards,
Jan Danielsson

___
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] Fossil vs. Git/Mercurial/etc.?

[Jan Danielsson]

On 12/18/12 22:50, j. v. d. hoff wrote:
 the NetBSD example seems to indicate that fossil's has performance problems
 for such projects with a massive code base. is this still the state of
 affairs?

   Last time I used my NetBSD fossil repository, it was still pretty
much unusable. I don't think anything has changed on that front since then.

   I have a pretty high-powered PC, and it still takes a few hours for
rebuilds. For a friend of mine, who has a Pentium3-class system, pulling
latest changes and rebuilding the NetBSD fossil repository takes around
~24h each time.

 not that this would matter for 99.9% of all projects.

   Definitely true.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/15/12 05:26, Joe Mistachkin wrote:
 My opinion is that backward compatibility should be retained because various
 people, including several that may not be involved in this discussion, have
 existing scripts and other automation that relies upon the current behavior.

   I'm going to speculate that this will affect very few users in the
end (and that they'll survive the change without any problems). Do you
actually know of any such cases; if so, would you care to explain the
work-flow so we get a better understanding of how they are used (more
importantly; so we understand how dangerous such a change would be)?

   In particular, with the proposed change there's no chance of loss of
data as I see it. If the scripts fail, the data is still in the
repository (again, no one is suggesting fossil blindly remove files).

   ..while the proposed change will affect many users (in a positive way).

   (And yes, I do believe that numbers matter. Not entirely, but
sufficiently in this case).

 1. Retain the existing behavior for all current commands and aliases.  It is
far too dangerous to change the DEFAULT semantics of these commands now.

   I don't agree.

   Of those I have introduced to fossil most of them have complained
about the mv/rm command (I think I've found a bug..). One user in
particular has never used SCM's before, so he had no preconceived ideas
with regards to SCM's. I know how bad anecdotal evidence is in a
universal discussion, but I firmly believe my friends and
acquaintances are representative enough for me to make a somewhat valid
extrapolation.

   If every user that I introduce to fossil who uses mv or rm comes to
me and says they've found a bug, then I feel it's a problem in fossil,
not the users.

   Not to mention the times it's been brought up on the mailing list and
other Internet-forums.

 2. Add entirely new commands named relocate (for mv) and obliterate (for
rm) that will perform actions on the repository itself as well as the
 file system.

   Obliterate has shun connotations for those who have used Perforce,
If we go with different names, I would prefer another name for the commands.

   mv and rm are good, because they make sense in Unix.

   As a new user, I would have expected relocate and obliterate to
be a database only operations. For me, then rather than two commands
which has behavior which doesn't make sense, we'd have four.

   I vote no, and again reaffirm my vote for the suggestion drh wrote
last night (local time).

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/15/12 11:24, j. v. d. hoff wrote:
[---]
 and I do not buy the it'll be really dangerous for so many people 
 prophecy. of course, if one really tries hard one can manage to get
 things messed up on disk (change lots of things in tracked files, but
 don't ever check in (clever) and then decide to stop tracking the files
 and issue 'fossil rm' assuming the files are left alone on disk and only
 then discover they were not). the transition period should guarantee
 that this will not evelove into a real-world problem I'd say.

   *nods in major agreement*

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/16/12 00:36, Joe Mistachkin wrote:
[---]
 2.  [---] On the other hand, if the
 mv and rm commands were to perform their file system actions
 prior to commit, would revert need to bring the previous files
 back to life?  That does not make sense.

   Why not?

   $ fossil rm foo.txt
   foo.txt deleted from filesystem, and marked for removal in the
repository.
   ...ops, wrong file..
   $ fossil status
   foo.txt   DELETED
   $ fossil revert foo.txt
   ..brings back the file in the filesystem, and unmarks file for removal..

   Why doesn't that make sense?

 3.  Related to the previous problem...  Think about very large files.
 If the rm command removes a very large file from the file system
 and later it needs to be restored, that is a whole lot of file I/O
 (potentially up to several GB).  This can be very hard on machines
 that are using SSD as their primary storage.

   First, I feel you're inventing problems to make arguments in order to
exclude features which address real world issues. (A little like the
script issue brought up earlier).

   Second (slightly off-topic), What's the problem with SSD and large
files? I have been using SLC SSD's since 2007, and since 2008 almost
exclusively mixed SLC and MLC SSD's on both servers and clients. On two
machines I regularly handle multi-GB files, and have not encountered any
issues which I haven't encountered with spinning-platter disks. I fail
to see why I would suddenly start having issues with large files because
I'm using fossil on SSD:s? (which, I'll admit, I have not).

   Anyway, even with the current behavior, one could fossil rm a few
GB-sized files, then remove the files from the filesystem, and later
realize one was in the wrong directory or something, so even with the
current situation one could end up needing to wait a while for a
reverted undelete.

   ...and also, when you revert a deleted file, doesn't fossil need to
scan through the entire file to see if it has changed? If you revert a
multi-GB file, you'll still need to spend some time waiting for it, no?

   There are lots of ways you can screw up, but the important thing is
that you can recover. I also think we have to assume that the normal
case is that people won't screw up, and assume that normally people
double check before they do something. (Wasn't that one of the insults
directed at those of us who want real mv/rm? That we just blindly do
things without thinking things through? Ironic twist (yes, I know you
weren't the one to say it, but someone else did)).

   Plus, if you know you're setting yourself up for such a situation,
then don't use the real rm; use the command which has retained the old
behavior (unmanage, for instance).

   And finally, if you're worried about performance, try working with
the netbsd repository. IMHO, there are far more common everyday
optimizations which need to be done looong before we worry about the
odd several GB data was deleted by mistake from a working tree..

 4.  What happens if a user tries to rm a file that does not exist in
 the repository?  Presumably, it would just issue an error message?

   Yes. (I recommend you read through the threads; some of the issues
you raise have been discussed previously).

 5.  What happens if a user tries to rm a file that has been shunned
 at some point?

   What's the current behavior, and why would it need to differ?

 6.  What happens if a user tries:  fossil rm . ?

   What happens them you type:
   $ rm .

   .. ?

   And what happens in other SCM's which support real rm?

 7.  What happens if a user needs to add all files in the directory
 except for generated files (i.e. fossil add .)?  After that
 point, normally *I* would rm the extra files; however, I do not
 want them deleted from the file system.

   You appear to be assuming that the suggestion is to change the
behavior of rm/mv and not retain the current behavior in any shape or
form. The suggestion which finally seemed to have pleased (mostly) both
sides was:


Stage 1:
(a) fossil rm -f deletes from disk (if it is safe to do so)
(b) fossil rm works as currently, but prints a warning message that it
will delete from disk in a future release.
(c) fossil delete works as currently
(d) fossil unmanage added as an alias for fossil delete

Stage 2 (after a stage 1 has been released for a while):
(e) fossil rm works just like fossil rm -f


   So, you'll be able to continue doing exactly what you are doing sans
s/rm/unmanage/. Everyone gets the behavior they want; others who
previously opposed real mv/rm seem to think that the latest suggestion
was a good compromise. For a brief moment, I thought that both sides
getting what they want would be the end of it..


   How come all these points you listed aren't issues with other source
management systems which have real rm/mv?

-- 
Kind regards,
Jan Danielsson

Re: [fossil-users] why does `fossil rm' not do the real thing?

[Jan Danielsson]

; some of the issues
 you raise have been discussed previously).
 
 Frankly, I've been trying to avoid getting involved in this discussion
 at all.  If people really want mv and rm to perform file system
 operations, they can already:
 
 1. Write a wrapper script that performs the operations.
 2. Customize their local Fossil binaries to include the necessary code.

   Or, we can change the behavior of mv/rm, implement the unmanage and
corresponding move command. Two or three users will sulk for a week,
get over it and then continue living on as nothing has happened. And all
the new users who expect the canonical behavior of mv and rm will no
longer need to be surprised.

 
 Stage 1:
 (a) fossil rm -f deletes from disk (if it is safe to do so)
 (b) fossil rm works as currently, but prints a warning message that it
 will delete from disk in a future release.
 (c) fossil delete works as currently
 (d) fossil unmanage added as an alias for fossil delete

 Stage 2 (after a stage 1 has been released for a while):
 (e) fossil rm works just like fossil rm -f
 
 
 I agree with (1a), (1c), and (1d).  I disagree with all the others,
 especially (2e).

   Well, as far as I can see, you're the only one remaining who won't
budge. It seems that the others have accepted it as a good compromise.

   We get the real rm/mv, the principle of least surprise for new users,
a canonical behavior for mv/rm, and the old behavior (just under a new
name). Everybody wins! (?)

   How come all these points you listed aren't issues with other source
 management systems which have real rm/mv?
 
 Frankly, I don't use the those other systems on a regular basis and I
 really do not care what they do.  Sorry.

   You're missing the point; whatever problems with the actual
implementation, somehow others have managed to work around them and made
systems which work and that people are happy with. And I'm pretty sure
we can do it too.

   Anywho, I think I've had to repeat every point I've made 10 times
now. Either I'm incapable of making myself understood, or people are
just plainly ignoring me. Whatever the reason, I'm starting to feel that
wonderful feeling of futility creeping up, which I guess is a good time
to give up. :)

   I can assure you that this topic will be brought up again in the
future (without the help of any of the participants this time around).
I'm pretty sure that had we had the canonical mv/rm behavior from the
beginning, we wouldn't be having these .. er, but reverse, discussions.
Probably worth considering.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/14/12 00:23, Richard Hipp wrote:
 But, should there be an opt-in option to also make the disk changes?

   Yes -- definitely.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/14/12 00:56, Nolan Darilek wrote:
 Who would have guessed that something as simple as having rm remove the
 file from disk would prompt opponents to:
 
  * claim that I want Fossil to be like Git.
  * Call me lazy.
  * Insult my intelligence by claiming that I don't know what a VCS is or
 should do.
 
 Done with this thread. Keep it classy, detractors.

   100% agree.

   I must say, I'm not quite as fond of the fossil community as I once
was. I have no interest in being insulted further.

-- 
Kind regards,
Jan Danielsson

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

[fossil-users] Obvious solution to the rm/mv problem?

[Jan Danielsson]

Hello,

   It seems that some of those who are opposed to changing the behavior
of rm/mv are reaching a consensus that the names rm and mv were
poorly chosen, because they have a Unix connotation, and rename and
move has been suggested instead. So -- is there any reason we can't
have both?

   mv/rm - change to principle of least surprise

   move/remove - behaves like current mv/rm

   That way we all get what we want .. no?

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/15/12 01:06, Eric wrote:
[---]
 4) I am not criticizing people, merely what they say. I see evidence
 that they don't get where I'm coming from because they have only an
 incomplete idea of what this is all about.
 
 5) SCM stands for Software Configuration Management which is not the
 same thing as version control. Look it up. You will possibly hate it,
 but if you ever write software that can affect real lives or large
 amounts of money you will need to know about it.

   So SCM defines how rm and mv should behave? And in order to take
part of these definitions, to gain a complete idea of what this is all
about, one needs to write software which affects real lives or large
amounts of money?

   Well, I develop programs which *very* much can affect real lives, and
large amounts of money is involved. No one has invited me to any secret
organization where the *true* definition of SCM is revealed.


   Sorry, but I think you're being silly. You don't know any more about
these things than anyone else here. Calling you an ass was a little
harsh, but at the same time, you are stating that others are inferior to
you, yet you present nothing of substance to back it up. I understand
why people are get a little annoyed.

   You seem to be indicating that there's some exact definitions of an
SCM which will resolve the rm/mv issue once and for all. Rather than
to talk about affecting real lives and how much money is involved and
other irrelevant nonsense, post those exact SCM definitions which are
relevant to the mv/rm issues and we can judge that information directly.


-- 
Kind regards,
Jan Danielsson

___
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] Obvious solution to the rm/mv problem?

[Jan Danielsson]

On 12/15/12 03:15, Richard Hipp wrote:
[---]
 It is suggested to me (off-list) that it would be too disruptive to
 abruptly change the meaning of fossil rm to start deleting from disk.  So
 I propose a staged implementation:
 
 Stage 1:
 (a) fossil rm -f deletes from disk (if it is safe to do so)
 (b) fossil rm works as currently, but prints a warning message that it
 will delete from disk in a future release.
 (c) fossil delete works as currently
 (d) fossil unmanage added as an alias for fossil delete
 
 Stage 2 (after a stage 1 has been released for a while):
 (e) fossil rm works just like fossil rm -f

   I vote Yes to all the above.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/13/12 05:01, Themba Fletcher wrote:
 What's next? Replacing SQLite with individual files?

 Absolutely not, and statements like this do more harm than good because they
 willfully disregard the point of what is being expressed. The point is not
 to be alarmist and extreme, as statements like the above are. The point is
 to establish that there is a certain behavior that is expected, and Fossil
 does not exemplify that.
 
 Sure. But without fossil's deviation from the norm what possible
 reason would I have to choose it over mercurial or git?

   I recall a discussion about implementing a ? :-operator in a non-C
language a few years back. Some simply suggested why not use '? :'?,
and some developers said That's C -- we're not C. So someone posted a
convoluted syntax which it seemed like almost everyone hated, but the
hard core users said it was ok, because it wasn't C.

   I don't want decisions about fossil to be made on that basis. If we
change this behavior to the better, we'll become more like others, so we
can't have it.. Being different isn't of any value if the difference
doesn't imply improvement (in the case of mv/rm I think fossil's
behavior is inferior to others).

   Extrapolating make rm and mv behave main-stream to we'll become
just like mercurial or git seems to be a little of a stretch to me. I
have zero objections to becoming main stream with regards to certain
features if it means becoming better.


   Some of the reasons I use fossil are: I trust SQLite, SSL, I like
that it uses HTTP as its clone-protocol, the REMOTE_USER feature, I like
the web-ui (with all its features), I like the command line ui (mostly),
I like the strict DAG property of the repository, the built in wiki,
ticket system, user administration, etc.

   The fact that I have to perform two operations for something which
should only require one is _not_ a reason for me to chose fossil over
any other system. But more to the point: Even if I saw any value in the
separation, such a feature would still not be a reason for me to chose
fossil over any other system. It would have exactly zero bearing.

   I don't see changing the current rm/mv behavior as removing a selling
point of fossil (and frankly speaking, I'm quite surprised to see that
it's being treated as such). I see it more limiting the number of
replies to the question Ok, so you've brought up the pros with fossil.
Could mention some of the cons?. I don't think there are many
annoyances with fossil, so the mv/rm behavior is a relatively minor
issue in the grand scheme of things, but still -- could we make it do
all of the work, not just half of it, I would be pleased and have one
less con in my list.

-- 
Kind regards,
Jan Danielsson

___
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] why does `fossil rm' not do the real thing?

[Jan Danielsson]

On 12/11/12 23:08, K wrote:
 I agree with Themba. I like that Fossil is a separate repo 'world' from my 
 files. If this boundary is to be pierced, I think it should require passing 
 in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in 
 this example representing sync.
 
 I would like some friendly tip text after rm/et al are ran, such as:
 
 You have removed file1.h, file1.c from repo foo, you may want to remove them 
 from your working copy.

 Seems like a great way to remind, teach, and help all in-context and with 
 minimal overhead.

   Say during your lifetime you'll (re)move 1000 files in fossil
repositories. That means you'll in practice perform 2000 (re)move
operations (once in metadata, and once in the filesystem). At what point
would one expect to have been sufficiently reminded and taught how to
(re)move files?

   Personally, I have never learned anything of value from having to
(re)move files twice.

   And I don't really buy the It's safer argument either. I have
several times become confused over what operations I have actually
performed because the file-system isn't in sync with the operations I
have performed; and becoming confused over what operations one has
performed because the filesystem doesn't reflect it is not safe.

   I'm willing to bet that the number of times people will type fossil
mv/rm X Y and not actually want to mv/rm X to Y just afterwards is
vanishingly small. More to the point; let's reverse your -s-flag; I.e.:

   $ fossil mv X Y

   ... renames X to Y (metadata and filesystem).

   $ fossil -d mv X Y

   ... as in Don't actually move will only change the metadata, and
the user can then use the mv command afterwards to manually rename/move
the file in the filesystem.

   The last option doesn't make any sense at all. Which is sort of my
point.. I think such an option would be used roughly zero times; but
your proposed -s would be used almost 100% of the time (when people
learn about it). And this goes back to that ten things I hate about
git-list; when commands counter-intuitively require extra flags to get
the canonical behavior.

   (I did some serious refactoring recently which involved lots of mv
and a few rm, and it really annoyed me that my computer, which is
supposedly a machine for automating tasks, required me to perform an
extra manual step for each mv and rm). (Yes, I ended up scripting it in
the end .. but that just further annoyed me; why do I need to script
operations in fossil to get the canonical behavior?).

   I too am a little skeptical about adding too many settings to fossil,
but this is definitely one that I would think merits a setting if the
current (default) behavior is kept in 2.0.

   Sorry if this came out as a rant; it's not directed at anyone
personally, but like I said, I battled fossil rm/mv recently and I'm
still not completely over it. No flame-bait intended.

-- 
Kind regards,
Jan Danielsson

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

[fossil-users] click timeline to diff

[Jan Danielsson]

Hey,

   I know it's only a short-cut for something which we could do
before. But I love this new feature; it's one of those I didn't know
how much I wanted it until I started using it, and now I won't be able
to live without it.

   Fantastic feature!

-- 
Kind regards,
Jan Danielsson

___
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] Fossil as DLL?

[Jan Danielsson]

On 11/26/12 21:06, Richard Hipp wrote:
 fossil uses fork() quite enough, and its memory management depends on
 that, for
 what I understand.
 
 The fossil ui and fossil server commands use fork() on unix.  But
 fork() is not available on windows so we have the winhttp.c source file to
 work around that limitation.
 
 So Fossil does not depend on fork().  But the implementation of Fossil
 would be simplified if fork() were universally available.

   Oh, thanks for reminding me of something.

   When I downloaded the win32 fossil binary and installed it on a
64-bit windows, I noticed that the fossil ui won't work properly due to
that it fails to launch new processes. Running command line fossil
works, but starting new fossil processes from fossil appears to fail.

   My gut feeling is that there's a simple solution for this (other
programs must be launching new 32-bit processes from 32-bit processes in
win64, but I'm not well versed in windows, so I don't know exactly where
to look.

   Fixing it by building a 64-bit binary was trivial enough, but if we
could make the distributed binary play nice on 64-bit Windows it would
be great.

   Anyone know if there's a trivial fix?

-- 
Kind regards,
Jan Danielsson

___
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] Support for Win9x?

[Jan Danielsson]

On 09/13/12 16:02, Richard Hipp wrote:
 Is there any reason to try to keep Fossil working on windows9x?

   I don't think much Win9x development goes on today. But even if I'm
wrong, I would guess that the intersection between the sets Win9X
developers and Fossil users is roughly empty.

   Tag last win95-compatible version so anyone so inclined can dig it up
easily, just in case?

-- 
Kind regards,
Jan Danielsson




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

Re: [fossil-users] The future of markdown-in-fossil

[Jan Danielsson]

On 08/03/12 15:42, Stephan Beal wrote:
[---]
 Another consideration here is that the wiki has kind of fallen out of use,
[---]

   I don't know that that is true. The only proof of this I have seen
prior to this thread is that at times it's mentioned that the fossil
repository uses embedded wiki rather than the built in wiki.

   For my part, I use the built in editor/wiki command line on a daily
basis, and it would sadden me greatly if it is depreciated, or if
someone would scrap any ideas of enhancements to it due to the perceived
notion that no one uses it any more. ...that said, I realize I could be
the only one still using it. :)

   The embedded wiki is useful for pages which are versioned. But there
are lots of things which I write which principally aren't meant to be
versioned, such as wide-perspective project goals, code conventions,
security considerations, protocol requirements, etc. Things which are
true in the past, present and future. I also have a central repository
on a server which serves as reference pages (I collect notes on
administration of things I very rarely do, cool/useful shell tricks,
etc), and it would be too much hassle to use the embedded wiki system
for that.

   While I'm anyways on the topic of things which worry me a little..

   I travel by train a lot, and on the train I don't always have access
to an electrical socket, so I run the laptop on battery. For this reason
I often run without X (I want as good battery time as possible). Now, I
don't want to come off as one of those got off my lawn, you kids!
types, so I'll be very explicit: I'm 100% for all the AJAX:ish work
being done and considered. It adds a lot of value to the users
(including myself), so it should be there and continue to be worked on.

   That being said, I want to (as far as possible) be able to do what I
do with fossil at home even when I'm working on the train, in console
mode. This is the primary reason I would want markdown support (in the
built-in wiki and ticket system): I think it's easier to read/parse
(mentally) and write than any wiki syntax I've seen so far. And even if
we get a nice WYSIWYG editor for the web interface (in theory rendering
the stored format irrelevant), I'll still be sitting writing wiki
documents on the train in plain old vim, because there really isn't any
other option.

-- 
Kind regards,
Jan Danielsson




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

Re: [fossil-users] feature proposal: explicitly public branches

[Jan Danielsson]

On 02/26/12 03:09, altufa...@mail.com wrote:
 Why not just productize limsync?

   Going by what Brian Smith has written, it's a question of having time
do work on it and handling a few special cases.

   Brian, if you need any kind of assistance, please let us know. I
really want this feature.

-- 
Kind regards,
Jan Danielsson

___
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] Building fossil on Solaris

[Jan Danielsson]

On 02/19/12 23:21, Steve Bennett wrote:
[---]
 So your openssl needs -ldl?

   Not exactly; the problem stems from that zlib doesn't exist as .a
(only .so), so it requires dynamic linking (and dynamic linking needs -ldl).

 You can try the attached patch as a workaround.
 (This will not work for platforms which don't have/need -ldl)

   It solves it for dynamic linking; but I'm specifically looking to
statically link: OpenSSL isn't installed on all systems, and I want to
be able to copy the fossil binary around with as little hassle as possible.

   In practice, with the slight modifications I've done, fossil builds
as I want up until the last link, and it's trivial to copy  paste the
final command line and manually modify it to get it to run properly. So
my goal has been reached. However, I know from previous experience that
I'll forget about the details two months from now when I want to redo it
all, which is why I'm looking for a more automatic solution. :)

-- 
Kind regards,
Jan Danielsson

___
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] autosetup build issues

[Jan Danielsson]

On 02/19/12 23:28, Steve Bennett wrote:
   For the record (in case someone finds this via a web search): I think
 there's something odd about the openssl detection. I had built openssl
 without the shared option (so I only had the shared libraries). But
 
 Building without shared meant you only had the shared libraries??

   Oops; I meant I only had static libraries. Sorry for the confusion.

 even with configure --static (in fossil), I ran into linking problems.
 Building openssl with the shared option made those problems go away. I
 haven't looked into it more closely, as the workaround is trivial, and I
 think most people will have the shared libraries laying around anyway.
 With the fix I sent earlier, does openssl detection work properly?

   It started working once I had built the dynamic OpenSSL libraries.
That's what I thought felt odd -- the detection seemed to fail to find
the OpenSSL static libs, even though --static was passed.

[---]
 How about forget about static linking and just use dynamic linking?

   Oh, I got dynamic linking working yesterday; that's not a problem --
but as I wrote in my other mail, I'm specifically looking to dynamically
link (more specifically: with OpenSSL).

   (I stress that this is not something I'm doing to torture myself, I'm
using a network of several Solaris systems, and I want to be able to
build one fossil binary and move it around; so there's a practical
reason for my battle with static builds on Solaris).

 Can we address the dynamic configure/build issues, and then possibly
 revisit static linking?

   The dynamic linking works, but unfortunately on these particular
systems I want static linking. :)

-- 
Kind regards,
Jan Danielsson

___
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] autosetup build issues

[Jan Danielsson]

On 02/20/12 01:24, Richard Hipp wrote:
[---]
The dynamic linking works, but unfortunately on these particular
 [Solaris]
 systems I want static linking. :)
 
 I agree that static linking is nice.  Unfortunately, the Solaris developers
 of Sun and now Oracle disagree.
[---]

   It seems I'm in an uphill struggle; even more so than I initially
thought. I won't put any more work into the static linking then, as I
suspect I'm a corner case.

   Anywho, my primary concern was getting OpenSSL statically linked into
fossil -- and using a slightly modified version of the final link
command line I got what I wanted. And if anyone else needs/wants it, the
information is easily found via a web search.

-- 
Kind regards,
Jan Danielsson

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

[fossil-users] autosetup build issues

[Jan Danielsson]

Hello,

   I've been trying to get fossil to build using the auto-configurator
on Solaris/sparc 9, and have encountered some minor bumps in the road.

   For the record (in case someone finds this via a web search): I think
there's something odd about the openssl detection. I had built openssl
without the shared option (so I only had the shared libraries). But
even with configure --static (in fossil), I ran into linking problems.
Building openssl with the shared option made those problems go away. I
haven't looked into it more closely, as the workaround is trivial, and I
think most people will have the shared libraries laying around anyway.

   Now there are just two issues remaining, and unfortunately I'm not
quite sure what to do about them.

   1) The SunStudio compiler doesn't support -static; it uses -Bstatic
and -Bdynamic.

   2) While zlib is a system library on Solaris 9, it doesn't appear to
have libz.a (only libz.so). This means that the final link line needs to
look something like this:

   [...] -Bdynamic -L/opt/openssl-1.0.0g/lib -lz -ldl -Bstatic -lssl
-lcrypto -lnsl -lsocket


   My Tcl-Fu is painfully limited and hence I understand near-zero of
autosetup, but as far as I can gather the current autosetup/auto.def
isn't really designed to handle compiler differences and mix static and
dynamic linking?

   What I would like to do:

   1) Add compiler detection (In this case: find sunstudio, default to
whatever gcc does)

   2) Set dynamic/static link flags (-static vs -Bstatic, etc) depending
on compiler

   3) Introduce a DLIBS which will unconditionally be dynamically
linked, regardless of whether --static is used or not.

   I realize there's something conceptually very wrong about dynamically
linking when it was explicitly requested by the users that static
linking be used. At the same time, the way I look at it, the project
should build and run on standard OS installations, with as few separate
dependencies as possible.

   Input is welcome.

-- 
Kind regards,
Jan Danielsson

___
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] Building fossil on Solaris

[Jan Danielsson]

On 02/17/12 03:00, Steve Bennett wrote:
[---]
 No problem. I've pushed the fix into autosetup and updated autosetup
 on a branch, so perhaps Richard will merge this fix at some point.

   I've encountered two other issues; one is fixed in the branch
jan-buildfixes.

   After applying the lib-fix, the linker complains; it can not find
dlsym, dladdr, dlopen, socket, connect, dlclose, dlerror and shutdown.

   config.log indicates that it's linking conftest__ with:

   -lssl -lcrypto

   ..while my old (manually patched) fossil Makefile contains:

   -lssl -lcrypto -ldl -lsocket -lnsl

   I, naively, tried inserting something along the line of if a host
*sun4* match is found, then append '-ldl -lsocket -lnsl' to LIBS, but
it made no difference. I don't know if I don't understand the build
system or Tcl. (I removed the if, and simply told it to always add
those extra libraries to LIBS, but it didn't, so I assume it's the build
system I don't understand). Any help is appreciated.

-- 
Kind regards,
Jan Danielsson

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

[fossil-users] Building fossil on Solaris

[Jan Danielsson]

Hello,

   I've built fossil on Solaris previously using the old Makefile
(requiring only very minor changes), but Makefile.classic seems to have
degenerated a little, so I thought I'd try to use configure et al),
but I end up with this:

   $ mkdir build
   $ cd build
   $ ../configure
   Error: No auto.def found in [...]/fossil/build
   Try: 'autosetup --help' for options
   $ ls -l
   total 0

   configure --help led me to try:
   $ ../configure --init
   I don't see configure, so I will create it.
   I don't see auto.def, so I will create a default one.
   Note: I don't see Makefile.in. You will probably need to create one.
   $ ls
   auto.def   configure

   The system is (correctly) being identified as:
   Host System...sparc-sun-solaris2.9
   Build System...sparc-sun-solaris2.9


   Which are the usual suspects when Makefile.in doesn't get created?

-- 
Kind regards,
Jan Danielsson

___
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] Building fossil on Solaris

[Jan Danielsson]

On 02/17/12 02:23, Steve Bennett wrote:
[.. FOO=bar ; export FOO ..]
 And let me know if that solves the problem?

   Ah, yes. Good ol' Solaris /bin/sh.

   That was it. I can't believe I missed that; I have been bitten by
that particular limitation of Solaris' /bin/sh a few times before.

   (Yes, I know Solaris technically does it right, and I respect that,
but it's getting a little old running into this problem every five-six
months or so).

   Thanks!

-- 
Kind regards,
Jan Danielsson

___
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] Retro side-by-side diffs

[Jan Danielsson]

On 02/04/12 11:08, altufa...@mail.com wrote:
 Same here. I like the colorful diff.
 
 But I would like to know (sorry if I missed) what's th eproblem with color 
 sbs and what are we getting with retro sbs?

   The reason is that we have two different places in the code which do
the same thing (create side-by-side diffs), but they do it in different
ways.

   Having them consolidated has benefits. (Smaller binary, much easier
to maintain, adding/changing features only requires it to be done in one
place, etc). The original sbsdiff was hard-coded for html (it will not
translate to the console), the retro sbsdiff works for both console and
displaying it in a pre html-section.

-- 
Kind regards,
Jan Danielsson

___
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] Retro side-by-side diffs

[Jan Danielsson]

On 02/03/12 16:25, Richard Hipp wrote:
[---]
 Are there strong preferences one way or another?

   There are two aspects I prefer with the original:
   - I think color coding makes it easier to get a quick overview of
what's happened in a diff. (I see a lot of red is roughly
optimizations, I see a lot of green is roughly New features).
   - I haven't looked at the code lately, but does the web sbsdiff
support the width argument in some manner? For quite a few diffs I've
been looking at lately, static 80 characters wide panes leaves a lot of
empty wasted space, due to short lines.

   Those points aside, I strongly support the idea of unifying the two,
so overall I'm for the retro sbsdiff.

-- 
Kind regards,
Jan Danielsson

___
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] Retro side-by-side diffs

[Jan Danielsson]

On 02/03/12 17:01, Tomek Kott wrote:
 My preference would be to keep the color SBS diffs, at least as a skin
 option or something, since I find it easier to notice changes and match
 them up. Maybe somewhere in the documentation on the header / skin, there
 could be css for a default coloring of the sbs diffs that one could copy
 into the header?

   The layout is so fundamentally different that it's not really
possible to do it that easily. In essence, the old sbsdiff used HTML
(tables and such), the new one essentially creates a textfile and
shows it in a pre-formatted section.

   That said, it shouldn't be impossible to get color coding with the
new/retro version: When I started working on the original sbsdiff,
someone was afraid I was going to break their javascript solution for
getting colored unified diffs. If javascript can be used to make
uncolored unified diffs colored, then I see no reason the same couldn't
be done for side-by-side diffs.

-- 
Kind regards,
Jan Danielsson

___
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] Retro side-by-side diffs

[Jan Danielsson]

On 02/03/12 18:40, Stephan Beal wrote:
 I'm for color-coded. All of the reasons have already been listed in the
 thread.

 Same here.
 
 If not color coded, perhaps adding add/change/remove markers to the _start_
 of each line, since that would make JS-scripting the colorification
 relatively simple? (Loop over the lines, do a regex check on the start
 (change type + line number), and wrapping the affected line(s) in a styled
 span.)

   I wouldn't like that change very much. I think the way  and  are
used now is very intuitive, and it creates a nice separator column with
relevant meta data. I think it would be changing something which is more
intuitive to something less intuitive (for the human reader), just to
make it easier to regexp, which I don't really like.

   With that being said, it's just a personal preference, and not
something I'd put up a fight against.

   Though it occurs to me that if almost everyone will anyways be
sticking colorized diffs into their fossil repositories via javascript
hacks, then perhaps it should be able to output them without any
additions. :-/ When I started working on side-by-side diffs it was
suggested to me that it could be done using javascript instead, but I
thought to myself If everyone is going to be pasting these javascripts
(or references to them) into every project they have, it's the sort of
feature fossil should handle itself..

   How much work would it be to put together a proof-of-concept sbsdiff
colorizer? (I would do it myself, but I'm sorry to say my javascript-fu
is so weak that I wouldn't even be able to assist anyone wanting to take
on the project).

-- 
Kind regards,
Jan Danielsson

___
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] fossil and SSL

[Jan Danielsson]

On 11/13/11 12:39, ST wrote:
 3) as far as I understand if one accidentally starts fossil
 server/fossil ui - it will provide insecure access to the repository
 even if one had configured inetd/stunnel/fossil to use SSL, right? Is
 there a way to avoid such situations and force fossil to always use SSL?

   Depending on the situation, it may be relevant to note that fossil
ui only listens on localhost.

   fossil server does not currently support SSL, though if there's
interest in this, I can look into it.

   (For completeness, I mention setting up Fossil as a cgi application
using apache, because you can fine-tune access to the repository using
client certificate rules).

 4) what happens if one autosync/pull/push from a remote repository, does
 it also expose the local repository as in 3) ?

   I don't quite understand what you're asking -- are you asking if
sync/pull/push temporarily starts a server? If that's the case, then the
answer is no.

-- 
Kind regards,
Jan Danielsson




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