Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

[Lonnie Abelbeck]

On Oct 18, 2017, at 8:04 AM, Richard Hipp  wrote:

> On 10/18/17, Warren Young  wrote:
>> On Oct 18, 2017, at 3:44 AM, Warren Young  wrote:
>>> 
>>> The more web apps that ship with stringent Content-Security-Policy
>>> headers, the fewer arguments we’ll have for allowing JS on web pages.
> 
> I'd never heard of Content-Security-Policy before.  A quick scan
> suggests that I need to modify Fossil to make use of it.
> 
> Target policy:  default-src: 'self'
> 
> That means, no more in-line javascript, which will be a hassle to work
> around.  I'll have to add a "/fossil.js" resource that contains
> various scripts and insert the JSON data used to drive those scripts
> as 

Re: [fossil-users] Fossil backup snapshots using Tarsnap

[Lonnie Abelbeck]

On Sep 26, 2017, at 10:35 AM, Warren Young  wrote:

>> fossil sqlite3 .dump -R /mnt/kd/fossil/astlinux.fossil > dump2
>> --
>> The dump2 INSERT INTO table names are "double-quoted".
>> ex: INSERT INTO "tag" VALUES(1,'bgcolor’);
> 
> The quotes are both legal SQL and unnecessary, since Fossil doesn’t have 
> spaces or other problematic characters in its table names.
> 
> But, Fossil 2.3 with a pre-release of SQLite 3.20.0 embedded does not 
> unnecessarily quote identifiers here, for whatever that’s worth.
> 
>> Of course all the sqlite3 versions will be changing over time anyway.
> 
> It’s almost certainly fine, particularly in the forward direction.

Thanks Warren for your comments ... yes we are due a Fossil version bump at 
some point.

Lonnie


___
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 backup snapshots using Tarsnap

[Lonnie Abelbeck]

On Sep 26, 2017, at 9:01 AM, Warren Young <war...@etr-usa.com> wrote:

> On Sep 26, 2017, at 7:10 AM, Lonnie Abelbeck <li...@lonnie.abelbeck.com> 
> wrote:
>> 
>> sqlite3 /mnt/kd/fossil/astlinux.fossil .dump > 
>> "$CUSTOM_BACKUP_DIR/astlinux.fossil.dump”
> 
> [snip]
> 
>> This seems to work well with limited testing ... Am I missing anything ?
> 
> That’s more or less what we do here for our off-site backups.  The few times 
> we’ve tried to reconstitute a working .fossil file from one of those backups, 
> it’s worked.
> 
>> Any issues with the command line sqlite3 being a different version with 
>> minimal compile time options than the built-in fossil sqlite3 ?
> 
> Probably not, but there’s no reason you have to even bring that worry up: 
> just use Fossil itself to do the dump:
> 
>$ fossil sqlite3 .dump -R /mnt/kd/fossil/astlinux.fossil ...

Thanks Warren,

Interesting ...
--
# sqlite3 --version
3.20.1 2017-08-24 16:21:36 
8d3a7ea6c5690d6b7c3767558f4f01b511c55463e3f9e64506801fe9b74dce34

sqlite3 /mnt/kd/fossil/astlinux.fossil .dump > dump1
--
The dump1 INSERT INTO table names are not quoted.
ex: INSERT INTO tag VALUES(1,'bgcolor');

--
# fossil sqlite3 --version -R /mnt/kd/fossil/astlinux.fossil 
3.17.0 2017-02-13 16:02:40 ada05cfa86ad7f5645450ac7a2a21c9aa6e57d2c

fossil sqlite3 .dump -R /mnt/kd/fossil/astlinux.fossil > dump2
--
The dump2 INSERT INTO table names are "double-quoted".
ex: INSERT INTO "tag" VALUES(1,'bgcolor');


I think I will stick to using the native sqlite3 CLI for backups and restores.  
Of course all the sqlite3 versions will be changing over time anyway.

Lonnie

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

[fossil-users] Fossil backup snapshots using Tarsnap

[Lonnie Abelbeck]

Greetings,

Our AstLinux Project just added Tarsnap https://www.tarsnap.com support and we 
want to (efficiently) backup our Fossil database.

Since Tarsnap does deduplication before compression and encryption, it is most 
efficient with uncompressed text-ish files.

So, in my Tarsnap backup pre-script currently I do ...
--
sqlite3 /mnt/kd/fossil/astlinux.fossil .dump > 
"$CUSTOM_BACKUP_DIR/astlinux.fossil.dump"
--
And have Tarsnap include "$CUSTOM_BACKUP_DIR" in the archives. (other sqlite3 
dumps there as well)

This seems to work well with limited testing ... Am I missing anything ?

Any issues with the command line sqlite3 being a different version with minimal 
compile time options than the built-in fossil sqlite3 ? (all relatively recent 
versions)

Lonnie

___
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 2.1 beta. Was: Progress report of Fossil 2.x

[Lonnie Abelbeck]

On Mar 5, 2017, at 5:01 PM, Richard Hipp  wrote:
> The big change is that now Fossil will actually generate SHA3-256
> hashes for new artifacts, if you ask it to, or by default in new
> repositories.  See
> https://www.fossil-scm.org/fossil/doc/trunk/www/hashpolicy.wiki for
> details.

Kudos to Richard, the Fossil team and all that contributed ideas for this 
Fossil "Hash Policy".  It appears every corner-case is covered.

Lonnie

___
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 Version 2.1 (prerelease)

[Lonnie Abelbeck]

On Mar 5, 2017, at 10:15 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 3/5/17, Lonnie Abelbeck <li...@lonnie.abelbeck.com> wrote:
>> For what is planned for Fossil 2.1, will new repos created using 2.1 using:
>> --
>> fossil init --sha1 repo.fossil
>> --
>> be compatible with recent Fossil 1.x versions ?
> 
> Yes.

Thanks Richard,

> But why would you want to do that?  Fossil 2.0 is out and 2.1 will be out 
> soon.

We use a fossil repo to track configuration files on an embedded system 
(Asterisk PBX, etc.).

Compatibility between fossil versions far more important to us than any 
practical issue with SHA1.  Users can upgrade and revert firmware, possibly 
containing any version of Fossil.

BTW, I just committed Fossil 2.0 for our next release.  We do appreciate the 
option to use SHA3 when we decide to.

Thanks the world-class project, Fossil.

Lonnie

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

[fossil-users] Fossil Version 2.1 (prerelease)

[Lonnie Abelbeck]

For what is planned for Fossil 2.1, will new repos created using 2.1 using:
--
fossil init --sha1 repo.fossil
--
be compatible with recent Fossil 1.x versions ?

Ref: Add the --sha1 option to the "fossil new" command, to simplify the 
creation of new SHA1-only repositories.
http://fossil-scm.org/index.html/vinfo/91f5ad9b94ef47d2?sbs=0

Lonnie

___
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.37 segfault, web interface "Login" as nobody with "a" capabilities

[Lonnie Abelbeck]

BTW, this also segfaults in Fossil 1.35, only discovered it by randomly 
clicking, testing 1.37.

Lonnie

On Jan 28, 2017, at 11:47 AM, Lonnie Abelbeck <li...@lonnie.abelbeck.com> wrote:

> I recently upgraded fossil to 1.37 for our project (cross-compiled from 
> source).
> 
> In our case the "nobody" user has "a" Capabilities.  This is desired since 
> fossil (listening on 127.0.0.1) is accessed via an authenticated HTTPS proxy 
> using lighttpd.
> 
> In the web interface, click on "Login" and while not logged in, the "Change 
> Password" appears.
> --
> Change Password for user :
> --
> If the {Change Password} button is clicked, fossil segfaults.
> 
> Lonnie
> 
> fossil version -v
> 
> This is fossil version 1.37 [1669115ab9] 2017-01-16 20:58:54 UTC
> Compiled on Jan 28 2017 10:53:10 using gcc-4.8.3 (64-bit)
> Schema version 2015-01-24
> zlib 1.2.11, loaded 1.2.11
> SSL (OpenSSL 1.0.2k  26 Jan 2017)
> UNICODE_COMMAND_LINE
> DYNAMIC_BUILD
> SQLite 3.16.2 2017-01-06 16:32:41 a65a62893c
> SQLITE_ENABLE_DBSTAT_VTAB
> SQLITE_ENABLE_FTS3
> SQLITE_ENABLE_FTS3_PARENTHESIS
> SQLITE_ENABLE_FTS4
> SQLITE_ENABLE_FTS5
> SQLITE_ENABLE_JSON1
> SQLITE_LIKE_DOESNT_MATCH_BLOBS
> SQLITE_OMIT_DECLTYPE
> SQLITE_OMIT_DEPRECATED
> SQLITE_OMIT_LOAD_EXTENSION
> SQLITE_OMIT_PROGRESS_CALLBACK
> SQLITE_OMIT_SHARED_CACHE
> SQLITE_SYSTEM_MALLOC
> SQLITE_THREADSAFE=0
> SQLITE_USE_ALLOCA
> 
> 
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[fossil-users] fossil 1.37 segfault, web interface "Login" as nobody with "a" capabilities

[Lonnie Abelbeck]

I recently upgraded fossil to 1.37 for our project (cross-compiled from source).

In our case the "nobody" user has "a" Capabilities.  This is desired since 
fossil (listening on 127.0.0.1) is accessed via an authenticated HTTPS proxy 
using lighttpd.

In the web interface, click on "Login" and while not logged in, the "Change 
Password" appears.
--
Change Password for user :
--
If the {Change Password} button is clicked, fossil segfaults.

Lonnie

fossil version -v

This is fossil version 1.37 [1669115ab9] 2017-01-16 20:58:54 UTC
Compiled on Jan 28 2017 10:53:10 using gcc-4.8.3 (64-bit)
Schema version 2015-01-24
zlib 1.2.11, loaded 1.2.11
SSL (OpenSSL 1.0.2k  26 Jan 2017)
UNICODE_COMMAND_LINE
DYNAMIC_BUILD
SQLite 3.16.2 2017-01-06 16:32:41 a65a62893c
SQLITE_ENABLE_DBSTAT_VTAB
SQLITE_ENABLE_FTS3
SQLITE_ENABLE_FTS3_PARENTHESIS
SQLITE_ENABLE_FTS4
SQLITE_ENABLE_FTS5
SQLITE_ENABLE_JSON1
SQLITE_LIKE_DOESNT_MATCH_BLOBS
SQLITE_OMIT_DECLTYPE
SQLITE_OMIT_DEPRECATED
SQLITE_OMIT_LOAD_EXTENSION
SQLITE_OMIT_PROGRESS_CALLBACK
SQLITE_OMIT_SHARED_CACHE
SQLITE_SYSTEM_MALLOC
SQLITE_THREADSAFE=0
SQLITE_USE_ALLOCA



___
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 HN

[Lonnie Abelbeck]

On Oct 9, 2016, at 8:31 PM, Richard Hipp  wrote:

> https://news.ycombinator.com/item?id=12673229

Our project uses Fossil to track configuration files for various open source 
packages, git was a non-starter for our small, embedded 50 MB image.

Fossil's small footprint and efficiency with built-in web tools makes it apples 
vs. oranges to most other VCS.

Lonnie

___
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] Release 1.35 checksums?

[Lonnie Abelbeck]

On Jul 1, 2016, at 3:42 PM, Ross Berteig <r...@cheshireeng.com> wrote:

> On 7/1/2016 10:11 AM, Lonnie Abelbeck wrote:
>> It seems the Checksums are on a different site from the downloads,
>> raising the bar for mischief. BTW including 1.35 now.
>> http://www.hwaci.com/fossil_download_checksums.html
> 
> FYI, Hwaci is D. R. Hipp's company that owns the assigned copyrights to all 
> work on fossil. Quoting that page, "Hipp, Wyrick & Company, Inc., or "Hwaci" 
> for short, is a small North Carolina company providing knowledge services to 
> clients around the world since 1992."
> 
> That site is as official as fossil-scm.org.

Indeed, and this requires a bad guy to hack two different servers to create 
bogus downloads and SHA1's.  As usual, well done D. R. Hipp.

Lonnie

___
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] Release 1.35 checksums?

[Lonnie Abelbeck]

On Jul 1, 2016, at 11:39 AM, Warren Young  wrote:

> On Jun 30, 2016, at 7:21 PM, Todd C. Olson  wrote:
>> 
>> The checksum file on the down load page only has values for up to v1.34
>> Where do we get the values for v1.35
> 
> Why do you trust such things in the first case?
> 
> If you’re expecting the checksum to protect you against someone hacking the 
> web site and uploading malware, they can modify the checksums on the web site 
> at the same time.

It seems the Checksums are on a different site from the downloads, raising the 
bar for mischief.  BTW including 1.35 now.

http://www.hwaci.com/fossil_download_checksums.html

Lonnie

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

[fossil-users] [patch] Default skin, show Release Version

[Lonnie Abelbeck]

Hi,

At a quick glance there does not seem any way to determine the Fossil Release 
Version from the web interface.

It seems some skins show the Release Version in the footer, and some do not.  I 
would like to request the default skin to do so as per this trivial patch...

@@ -1,6 +1,6 @@
 
 This page was generated in about
 puts [expr {([utime]+[stime]+1000)/1000*0.001}]s by
-Fossil version $manifest_version $manifest_date
+Fossil v$release_version $manifest_version $manifest_date
 
 


resulting in a footer:
--
This page was generated in about 0.016s by Fossil v1.34 [62dcb00e68] 2015-11-02 
17:35:44
--

Then I have a question, to make the above patched "skin" work, it seems Fossil 
caches the default skin when the repo is created, and Fossil is smart enough to 
determine if the cached skin differs from the new version of the skin and you 
have to manually install the new (patched) skin.  Am I understanding this 
correctly ? 

Lonnie

___
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] diff after update

[Lonnie Abelbeck]

On Sep 11, 2015, at 7:19 PM, Scott Robison  wrote:

> On Fri, Sep 11, 2015 at 6:07 PM, Steve Stefanovich  wrote:
> Clever, but awkward in my opinion; the first place to look for such a feature 
> would be under diff command. At least for me, that is.
> 
> My vote is for diff --from|--to undo, where 'undo' is a special tag, same as 
> 'ckout' in different context. I think it fits in such paradigm nicely.
> 
> The person who names branches 'undo' can be perhaps warned in the command 
> help to use the hash instead.
> 
> S.
> 
> Here is the stash version of diff:
>  fossil stash diff ?STASHID?
>  fossil stash gdiff ?STASHID?
> 
> Why not do it the same way for undo? It seems to be most in line with 
> precedent. Perhaps because undo doesn't currently have subcommands, just 
> options. Still, it would be the most intuitive thing based on existing 
> practice.
> 
> -- 
> Scott Robison

+1

Editing the "stash" help added to "undo" would look something like...

-- snippet --

 fossil undo diff ?DIFF-OPTIONS?
 fossil undo gdiff ?DIFF-OPTIONS?

Show diffs of the current working checkout and what that
checkout would be if "undo" were applied.

SUMMARY:
 fossil undo
 fossil undo [g]diff ?DIFF-OPTIONS?

--
Lonnie

___
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] Synology Diskstation Package

[Lonnie Abelbeck]

On Aug 29, 2015, at 2:57 PM, Lonnie Abelbeck <li...@lonnie.abelbeck.com> wrote:

> Hi,
> 
> Has anyone here looked into getting Fossil added as an official package with 
> the Synology Diskstation ?
> 
> Synology currently supplies Git and GitLab, and SVN packages, clearly Fossil 
> should also be there.

I was able to get Fossil running on my Synology DS713+ by using Docker, 
standard for "+" Diskstations starting with DSM 5.2 .

Add the Docker package if you haven't already.

Registry -> nijtmans/fossil (Thanks to Jan Nijtmans here)

Image -> Launch -> Launch with Docker Run (Required to change the Execution 
Command)

Step 1
--
Container Name: Fossil

Port Settings: (Define a Local Port you want)
Local Port   Container Port  Type
8055   8080TCP
--

Advanced Settings...

Volume (Folder)
--
/someuser/fossil  -> /opt/fossil/repo
--

Environment (Execution Command)
--
/usr/bin/fossil server --port 8080 --repolist /opt/fossil/repo
--

Container -> [ _  1 ] (start it up)

Then populate your "/someuser/fossil" folder with *.fossil repositories.  You 
can perform
--
fossil init --admin-user admin /opt/fossil/repo/foo.fossil
--
from a running Docker container, but the Terminal pane does not support 
copy/paste.

I haven't tried, but adding a Docker stunnel container could also add HTTPS 
support.

Lonnie

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

[fossil-users] Synology Diskstation Package

[Lonnie Abelbeck]

Hi,

Has anyone here looked into getting Fossil added as an official package with 
the Synology Diskstation ?

Synology currently supplies Git and GitLab, and SVN packages, clearly Fossil 
should also be there.

There seems to an official process for this...

Synology Dev Center
https://www.synology.com/en-us/support/developer

But, if anyone has a contact within Synology there might be an easier method.

Regardless, a few decisions like how Fossil would be hooked-up... fossil 
server ... or via cgi-bin would have to be decided as well what the user gets 
to define in the package configuration panel.

Ideally, someone here finds this an interesting idea and is willing to take the 
lead.

There appears to be some unofficial ipkg feeds for Fossil with the Diskstation, 
but it would give Fossil extra visibility if it were available as an official 
package.

Lonnie

___
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 added to AstLinux

[Lonnie Abelbeck]

On Aug 28, 2015, at 11:40 AM, Ron W ronw.m...@gmail.com wrote:

 On Thu, Aug 27, 2015 at 9:47 PM, Lonnie Abelbeck li...@lonnie.abelbeck.com 
 wrote:
 On Aug 27, 2015, at 6:27 PM, Ron W ronw.m...@gmail.com wrote:
 
  Why a and not d (developer)? Seems to me that would cover the needed 
  permissions to manager the Astrix and AstLinux conf files.
 
 I meant 'v', not 'd' ('v' is developer permissions, which is a macro for 
 the combined permissions assigned to developer, anonymous' and 'nobody'.)
  
 Since the user has lighttpd's admin privileges under the AstLinux web 
 interface, it seemed reasonable to us that a privileges in Fossil would be 
 appropriate.  Possibly we are allowing some privilege we really don't want, 
 but in our testing things seemed appropriate.
 
 If there is some reference describing the extra permissions of 'a' vs. 'dei' 
 I would appreciate it.
 
 #1 under Notes in the User admin page states that 'a' (Admin) permissions are 
 Create and Delete Users. Since your user management is done outside Fossil, 
 this would seem to not be needed.
 
 Apparently, 'a' inherits 'v' permissions, though this is not mentioned. (Not 
 sure, have not tested this, but your experience implies it is inherited.)
 
 BTW, starting Fossil server with fossil server $REPOSITORY --scgi 
 --localhost --port 8055 (adding the --scgi option) - and configuring 
 lighttpd to treat Fossil as an SCGI service - will allow Fossil to know the 
 user name as authenticated by lighttpd. (see Fossil as SCGI on 
 https://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki)

Thanks Ron ! That is helpful, much appreciated.

Lonnie


___
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 added to AstLinux

[Lonnie Abelbeck]

Hi Ron,

On Aug 27, 2015, at 6:27 PM, Ron W ronw.m...@gmail.com wrote:

 Since any HTTPS access to /admin/fossil/ is authenticated by lighttpd, we set 
 Fossil's nobody permissions to a (admin) and add the admin user for s 
 (setup) permissions.
 
 Why a and not d (developer)? Seems to me that would cover the needed 
 permissions to manager the Astrix and AstLinux conf files.

Since the user has lighttpd's admin privileges under the AstLinux web 
interface, it seemed reasonable to us that a privileges in Fossil would be 
appropriate.  Possibly we are allowing some privilege we really don't want, but 
in our testing things seemed appropriate.

If there is some reference describing the extra permissions of 'a' vs. 'dei' I 
would appreciate it.

Lonnie


___
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 added to AstLinux

[Lonnie Abelbeck]

Hi Warren,

On Aug 26, 2015, at 5:28 PM, Warren Young w...@etr-usa.com wrote:

 On Aug 26, 2015, at 2:12 PM, Lonnie Abelbeck li...@lonnie.abelbeck.com 
 wrote:
 
 we wondered if it could be used to track changes to these configuration 
 files in a way a non-developer type could easily understand.
 
 Did you look at etckeeper, and if so, why did you reject it?
 
  https://joeyh.name/code/etckeeper/

I had not heard of etckeeper before, but seems to work around package managers, 
we don't have any.

The code we implemented to manage the fossil commit is quite small, we did 
not include any version control binary on our image until we added Fossil.

Our images are like firmware and size matters, currently around 50 MB 
compressed.


 
 Long story short, success, Fossil is a gem !
 
 Glad to hear it!  I’m sure there many Fossil users who can’t or won’t tell 
 how and why they are using it, so it is nice when someone decides to step out 
 of the shadows.
 
 Since any HTTPS access to /admin/fossil/ is authenticated by lighttpd, we 
 set Fossil's nobody permissions to a (admin) and add the admin user 
 for s (setup) permissions.
 
 Why?  Does doing one require the other, or does it merely *allow* the other?
 
 It seems to me that you had an opportunity to construct some defense-in-depth 
 here, but chose instead of replace one defense layer with another, so that 
 you still have a single point of failure.

AstLinux has it's own web interface (PHP), we run Fossil's web interface within 
an HTML iframe.  We do the same for Monit, Darkstat and phpLiteAdmin .  This 
allows for one common set of admin credentials to access these services.



 
 (Yes SourceForge SVN, our project is over 10 years old, old habits die hard 
 :-) )
 
 What with your newfound Fossil love and SourceForge turning evil,[1] maybe 
 it’s time to consider self-hosting your project in Fossil.
 
 I documented my process for migrating a 15-year-old svn repo to Fossil here, 
 which has some advantages over the method described on the Fossil pages:
 
http://goo.gl/Zr6YQw
 
 The attached script will require some local adjustment, but the code should 
 be clear enough to make that straightforward.

Thanks for sharing !  I'm sure that day will come. :-)

Lonnie


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