Re: [fossil-users] Random thoughts on Fossil v2

[Edward Berner]

On 7/22/2013 1:13 AM, Gautier DI FOLCO wrote:
2013/7/22 Stephan Beal >


The problem is the interpreter. i am not aware of a small
embedable JS interpreter. SpiderMonkey/Jaegermonkey are complex
and poorly documented. Google V8 is nice but (A) huge, (B) C++,
and (C) they recently made drastic API changes which invalidated
every single v8-using client out there (breaking 4-5 years of
accumulated code of mine, and i'll never have the time to fix it),
which means that very few people outside of Google can actually
use v8 at the moment. JS _would_ also be my first choice, if we
only had a small, well-maintained interpreter.i don't know TCL,
but the TCL and Fossil communities seem to be cosmically bound to
one another. There are relatively few well-established
small/embeddable interpreters. Lua, TCL, ... none others come to
mind (which are small).


I think you can have a look at lo (http://iolanguage.org/) which is a 
very tiny programming language.


From a quick glance at that page it looks like the Io Language is 
implemented in C99, which may preclude it from use in Fossil if (as I 
hope it does) Fossil chooses to remain at C89.


--
Edward Berner

___
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] Random thoughts on Fossil v2

[BohwaZ]

Le Mon, 22 Jul 2013 10:02:47 +0200, Stephan Beal
 a écrit :

> The problem is the interpreter. i am not aware of a small embedable JS
> interpreter. SpiderMonkey/Jaegermonkey are complex and poorly
> documented. Google V8 is nice but (A) huge, (B) C++, and (C) they
> recently made drastic API changes which invalidated every single
> v8-using client out there (breaking 4-5 years of accumulated code of
> mine, and i'll never have the time to fix it), which means that very
> few people outside of Google can actually use v8 at the moment. JS
> _would_ also be my first choice, if we only had a small,
> well-maintained interpreter.i don't know TCL, but the TCL and Fossil
> communities seem to be cosmically bound to one another. There are
> relatively few well-established small/embeddable interpreters. Lua,
> TCL, ... none others come to mind (which are small).

I heard one time of a small JS interpreter, probably from the Dillo
browser project, called SEE or Simple ECMAScript Engine. It's also
used in the hv3 web browser (TCL/Tk browser). Although it seems
unmaintained (last release in 2009), I found a new project of a compact
ECMAscript engine called duktape http://www.samivaarala.com/#duktape

> Stable incremental numbers are literally not possible to solve for
> DCVS systems, which is why the SHA's (geeky/unwieldy as they are) are
> used.

There is out there other encoding algorithms to replace hexa though,
like Bubble Babble which produces pronouceable words (and includes a
checksum), but it produces long strings. So I'm not sure it would be
more practical to speak about ticket
'xesaf-lenaf-denyk-gisof-gosik-guxex' rather than ticket '07d2dd143d'.
Although it would make your weekly meetings sound interesting :)


-- 
BohwaZ|  boh...@bohwaz.net   |   http://bohwaz.net/
---
.oO[ Une citation au hasard ...
En amour, l'important c'est la rencontre et la rupture,
entre les deux, ce n'est que du remplissage.
   ... http://bohwaz.net/misc/fortune  ]Oo.
___
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] Random thoughts on Fossil v2

[Edward Berner]

On 7/22/2013 7:30 PM, Joseph R. Justice wrote:


OS-level peculiarities: There are other multi-platform software 
projects which have to deal with these, both with peculiarities 
between similar types of platform, such as the various flavors of Unix 
and Linux, and between drastically different platforms, such as 
between the former versus the different versions of Windows, MacOS/X, 
ummm, VMS, the IBM mainframe OSen, etc etc etc.  All the major FOSS 
SQL databases have to deal with this, the Apache web server (Apache 
HTTPD) has to deal with this (they have Apache Portable Runtime IIRC), 
Gnu Emacs has to do this (tho that would certainly involve GPL 
licensed software), I'm sure there's plenty more...  Maybe there's 
stuff that can be stolen ^H^H borrowed from one or more of those to 
avoid having to roll your own.


Not particularly related to Fossil, but C-Kermit is an interesting study 
in extreme C portability.  I like the Program Logic Manual's list of 
guidelines for writing portable C ( 
http://www.kermitproject.org/ckcplm.html#x3 ).  (Note that C-Kermit also 
targets pre-ANSI C so a lot of the advice and techniques aren't relevant 
to Fossil.)




Strict C89 or commonly-supported C99 extensions: What platforms, and 
compilers on those platforms, do you want to be portable to?  If 
everything you care about is (non-buggy) C99, well...


Personally, I'd vote for Fossil to remain C89.  Specifically I'd like 
Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable 
target.


--
Edward Berner

___
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 Nijtmans]

On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> Hello,
>
> today I built fossil on cygwin64, and it built but "it didn't work". Cloning, 
> a
> line in os_win.c complained about not having permission to create a file (a 
> tmp
> file with some kind of random string) in C:/windows.
I can easily reproduce that (see below). The Cygwin folks made some local
modifications to sqlite, allowing cooperation between Cygwin and Windows
programs. Cygwin64 doesn't have those modifications yet.

2013/7/22 Martin Gagnon :
> I stop building fossil for cygwin long time ago and I found that cygwin
> version of fossil was a lot slower (with big repo) and I had problem
> when using the same checkout from cygwin and non-cygwin binary.

That should be fixed now. For details, see:


You can try it on Cygwin32 using
./configure --disable-internal-sqlite
There it should work fine now, but feel free to report any additional
problems you find.

On Cygwin64 that doesn't work yet due to the above mentioned reason:
$ ./configure --disable-internal-sqlite

$ make

$ ./fossil update
Autosync:  
SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_8td6VBhZb6xMX3V\etilqs_QL9aCIutNgLB3ZP) - The
system cannot find the path specified.
SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
system cannot find the path specified.
SQLITE_CANTOPEN: cannot open file at line 34071 of [cbea02d938]
SQLITE_CANTOPEN: statement aborts at 38: [CREATE TEMP TABLE
onremote(rid INTEGER PRIMARY KEY);] unable to open database file
./fossil: unable to open database file: {CREATE TEMP TABLE
onremote(rid INTEGER PRIMARY KEY);}

If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.

Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.

Thanks!

Regards,
   Jan Nijtmans
___
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

[Lluís Batlle i Rossell]

Great! Very informative. Thank you.

Do you happen to know if I can build and run programs for cygwin32, in a
cygwin64 installation? or I should run two cygwin setups in orthogonally, 32 and
64?

On Wed, Jul 24, 2013 at 10:33:38AM +0200, Jan Nijtmans wrote:
> On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> > Hello,
> >
> > today I built fossil on cygwin64, and it built but "it didn't work". 
> > Cloning, a
> > line in os_win.c complained about not having permission to create a file (a 
> > tmp
> > file with some kind of random string) in C:/windows.
> I can easily reproduce that (see below). The Cygwin folks made some local
> modifications to sqlite, allowing cooperation between Cygwin and Windows
> programs. Cygwin64 doesn't have those modifications yet.
> 
> 2013/7/22 Martin Gagnon :
> > I stop building fossil for cygwin long time ago and I found that cygwin
> > version of fossil was a lot slower (with big repo) and I had problem
> > when using the same checkout from cygwin and non-cygwin binary.
> 
> That should be fixed now. For details, see:
> 
> 
> You can try it on Cygwin32 using
> ./configure --disable-internal-sqlite
> There it should work fine now, but feel free to report any additional
> problems you find.
> 
> On Cygwin64 that doesn't work yet due to the above mentioned reason:
> $ ./configure --disable-internal-sqlite
> 
> $ make
> 
> $ ./fossil update
> Autosync:  
> SQLITE_CANTOPEN: os_win.c:34063: (3)
> winOpen(/var/tmp/etilqs_8td6VBhZb6xMX3V\etilqs_QL9aCIutNgLB3ZP) - The
> system cannot find the path specified.
> SQLITE_CANTOPEN: os_win.c:34063: (3)
> winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
> system cannot find the path specified.
> SQLITE_CANTOPEN: cannot open file at line 34071 of [cbea02d938]
> SQLITE_CANTOPEN: statement aborts at 38: [CREATE TEMP TABLE
> onremote(rid INTEGER PRIMARY KEY);] unable to open database file
> ./fossil: unable to open database file: {CREATE TEMP TABLE
> onremote(rid INTEGER PRIMARY KEY);}
> 
> If you have recently updated your fossil executable, you might
> need to run "fossil all rebuild" to bring the repository
> schemas up to date.
> 
> Just wait on the Cygwin64 people to bring out a new Sqlite package with
> the same fixes already done in Cygwin32.
> 
> Thanks!
> 
> Regards,
>Jan Nijtmans
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Scripting in Fossil v2

[Mark Janssen]

I would just like to add that fossil already has a defined "API" in the
sense that what a fossil repo and server are is described in
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say that
any truly useful fossil library should be built on those concepts.


On Wed, Jul 24, 2013 at 3:42 AM, Stephan Beal  wrote:

> On Wed, Jul 24, 2013 at 1:55 AM, Aaron W.Hsu  wrote:
>
>> against a fossil(3) library. This functionality can therefore be provided
>> by the fossil(1) executable program as well as from a separate shared
>> object against which the fossil(1) program links.
>>
>
> Right - that's just a question of how the modules/extensions are linked.
> That bit only affects how they are loaded/initialized, but not how they
> operate.
>
>  Once we recognize that these are all technically orthogonal, we can then
>> try to understand how they synergize together. For instance, it makes sense
>> that the fossil API that is accessible through shared objects loaded by
>> fossil(1) at runtime and the API provided by fossil(3) be the same.
>>
>
> i hadn't ever thought explicitly about them being available via fossil(1),
> probably because the matter of where the APIs are linked to/from doesn't
> change the fundamental design (which is where the work/energy is going at
> the moment).
>
>
>>  On the other hand, it doesn’t make much sense for the extension API to
>> be a part of fossil(3).
>>
>
> Not necessarily. Where exactly those bits will/should/could live isn't a
> problem i've considered much yet. i'm at the point where i can instantiate
> and destroy a fossil instance and create formatted output to a few
> different output channels, but not yet at a point where anything really
> interesting is happening, e.g. opening an existing repo DB will be the next
> step.
>
>
>>1. Should fossil(3) exist at all?
>>
>>
> That is a fair question. Despite my overall enthusiasm and hype regarding
> fossil(3), i do have concerns about whether it is truly going to work.
> Richard has also expressed skepticism - you're not alone! i do, however,
> think that it's an interesting enough problem to be worth trying out. If it
> turns out that it's not reasonable or doesn't fit, it'll get tossed aside.
> At this point there is _no_ commitment that fossil(3) will/should/must
> happen.
>
>
>>
>>1. What is the extension API?
>>
>>
> (Sorry, gmail is renumbering your entries when i split them.)
>
> i'm not yet that far along, but i expect to have some interesting
> discussions on that topic later.
>
>
>>
>>1.
>>2. What is the fossil API?
>>
>>
>> Notice that I’ve explicitly created a difference between the extension
>> API and the fossil API. I think this is not only important, but at the crux
>> of our particular current line of discourse. In particular, you’ve
>> mentioned a number of times that having a fossil API, such as what
>> fossil(3) might provide, sort of automatically entails extensibility and
>> scriptability. I disagree with the usage of those terms here. I think one
>> should distinguish clearly between the extension API and the fossil API.
>> There is no extension API in fossil(3).
>>
>
> i hadn't thought about those being separate until your post. i'll have to
> ponder why that separation is significant. i haven't yet gotten to the
> level of detail where i can just point to the function and say, "that does
> or does not fit."
>
>
>
>>  Namely, you cannot change the way that fossil operations work. Instead,
>> you are expected to have access to these operations as primitives for
>> writing other programs, but by and large you are not altering the behavior
>> of fossil itself.
>>
>
> Correct.
>
>
>>  An extension API is not for providing fossil operations to the rest of
>> the programming space, but is instead for the sole purpose of allowing one
>> to alter the behavior of the fossil operations themselves.
>>
>
> Yes, and building off of them to provide bigger or more special-purpose
> features. e.g. specialized timeline reports or exports to spreadsheets.
>
>
>
>>   Based on your prior messages, I think it is clear that you are talking
>> about the fossil API, and consider that to be the really sticky issue.
>>
>
> Right.
>
>
>>  I have no doubt that the fossil API itself is a very important and
>> tricky issue. However, I want to elevate the extension API question to the
>> fore here. What’s interesting and relevant here is not the fossil API, but
>> the extension API. And here I want to emphasize that the fossil API and the
>> extension API can both reasonably and technically exist *without* ever
>> having to create a shared fossil(3) library. Whether one should do that or
>> not is a different question, and important, but not the question I want to
>> focus on.
>>
>
> That's an interesting direction. i would at this point argue that until we
> know what the core fossil lib really should look like, that we can't say
> what wi

Re: [fossil-users] Fossil on cygwin64

[Jan Nijtmans]

2013/7/24 Lluís Batlle i Rossell :
> Do you happen to know if I can build and run programs for cygwin32, in a
> cygwin64 installation? or I should run two cygwin setups in orthogonally, 32 
> and
> 64?

I would recommend to compile fossil using:
make -f win/Makefile.mingw PREFIX=x86_64-w64-mingw32-
Then you get a WIN64 version of fossil.exe which
works in any environment (Cygwin32, Cygwin64, Msys, CMD),
and is super fast.

All Cygwin64 and Cygwin32 dll's have the same name, so you
cannot mix executables from those two environments.

Regards,
Jan Nijtmans
___
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-login setting

[MaxJarek]

Hi,

My fossil works over http and https. I want to use setting option https-login 
but i have trouble.
Documentation says:
"Send login credentials using HTTPS instead of HTTP even if the login page request came via HTTP" 
but this don't working for me.


Fossil don't force https login. Any hints?


___
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

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:16:19AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > Do you happen to know if I can build and run programs for cygwin32, in a
> > cygwin64 installation? or I should run two cygwin setups in orthogonally, 
> > 32 and
> > 64?
> 
> I would recommend to compile fossil using:
> make -f win/Makefile.mingw PREFIX=x86_64-w64-mingw32-
> Then you get a WIN64 version of fossil.exe which
> works in any environment (Cygwin32, Cygwin64, Msys, CMD),
> and is super fast.

I think our main usage for a cygwin fossil is that we develop using a cygwin
terminal with bash and vim. And we want fossil to spawn vim properly on commit.

iiuc, a native fossil can't spawn a proper vim editor in the cygwin bash
terminal. Is it right? Do you know any workaround?

> All Cygwin64 and Cygwin32 dll's have the same name, so you
> cannot mix executables from those two environments.

Ah ok. Good to know!

Thank you,
Lluís.
___
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 Nijtmans]

2013/7/24 Lluís Batlle i Rossell :
> I think our main usage for a cygwin fossil is that we develop using a cygwin
> terminal with bash and vim. And we want fossil to spawn vim properly on 
> commit.

That should work, only you should do something like:
export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
I don't know vim enough to comment on that.

Windows Fossil nowadays uses Notepad.exe as default
commit editor, isn't that much easier?

Regards,
Jan Nijtmans
___
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

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > I think our main usage for a cygwin fossil is that we develop using a cygwin
> > terminal with bash and vim. And we want fossil to spawn vim properly on 
> > commit.
> 
> That should work, only you should do something like:
> export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> I don't know vim enough to comment on that.
> 
> Windows Fossil nowadays uses Notepad.exe as default
> commit editor, isn't that much easier?

notepad easier than vim? Not at all, for a brain trained on vim. :)
___
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

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> 2013/7/24 Lluís Batlle i Rossell :
> > I think our main usage for a cygwin fossil is that we develop using a cygwin
> > terminal with bash and vim. And we want fossil to spawn vim properly on 
> > commit.
> 
> That should work, only you should do something like:
> export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> I don't know vim enough to comment on that.

Ah, the point isn't bash; the point is at processes passing properly the fds
for the *terminal*. I guess that once you put a non-cygwin process in the family
tree, the children can't access the terminal ancestor properly.
___
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] Scripting in Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 10:43 AM, Mark Janssen wrote:

> I would just like to add that fossil already has a defined "API" in the
> sense that what a fossil repo and server are is described in
> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
> http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say
> that any truly useful fossil library should be built on those concepts.
>

i was recently wondering (haven't checked) whether the sync really belongs
in the core lib or if networking is an app-level detail? The file
format/manifest will (must) remain central to the design, and i started
sketching out interfaces for working with the manifests.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 8:38 AM, Edward Berner  wrote:

> Specifically, a repository's local state is not cloned (see 2nd paragraph
> of section 1.0 of http://www.fossil-scm.org/**
> index.html/doc/trunk/www/sync.**wiki).
>  Most of the local state can be cloned with other commands but you need
> to go a bit out of your way (and have extra permissions?) to do it.
>

Basically only security-relevant info is not cloned (e.g. user list).
Anything which is "content" is cloned. AFAIK shunned artifacts are skipped,
but i've never used shunning and could be very wrong.

It seems fair for those servers of a project which do house the full
> repository to be referred to as the central servers or central repositories.


But that's a convention between us mortals, and not one fossil knows about.
It remembers which repo it cloned from, but it doesn't give that repo any
real special status. If it did, and the Central one burned down in a fire
then fossil would be confused, perhaps even lonely. If there were some
"this repo is the central copy" flag (for us humans) then another copy of
the repo would need to set that flag to take over the responsibility. But
what, then, if 2 or 3 people each set that flag? The nature of distributed
systems makes (by design) any attempt at building a central authority very
difficult or impossible.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 9:38 AM, Edward Berner  wrote:

> Personally, I'd vote for Fossil to remain C89.  Specifically I'd like
> Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable
> target.
>

As a matter of course, i never explicitly use any C99 features except for
the 2 headers stdint.h and inttypes.h (for fixed-size integers and their
portable printf/scanf modifiers) but those work just when compiling in c89
mode, assuming your compiler has them. MSVC does not, but there are two
open source projects offering drop-in replacements for these headers for
MSVC. The current prototype code compiles with (-std=c89 -pedantic -Wall
-Werror), but does use those two C99 headers.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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

[Warren Young]

On 7/24/2013 02:33, Jan Nijtmans wrote:

 SQLITE_CANTOPEN: os_win.c:34063: (3)
winOpen(/var/tmp/etilqs_FoaHNBQa56cVGrh\etilqs_PXfZEjH5dBl8Cm5) - The
system cannot find the path specified.


I'm not sure whether this is a SQLite 3.7.17 thing or if it is due to 
one of the build option changes in recent versions of Cygwin SQLite. 
All I know is that it seems to be a new thing.


As you can see from the error, SQLite is generating a temp file name 
with backslashes in it.  This is purely wrong on Windows, whether 
running under Cygwin or not.


I haven't bothered looking any deeper into it than that.  I hope it just 
gets fixed for me in .18.  If not, I may have to hack around it in my 
next release of Cygwin SQLite.


In the meantime, some people have had luck setting the new environment 
variable CYGWIN_SQLITE_LOCKING=posix.  This means Cygwin SQLite won't 
interoperate well with Windows native SQLite, but if you don't need 
that, I believe it will bypass this problematic tmp file name generation.



Just wait on the Cygwin64 people to bring out a new Sqlite package with
the same fixes already done in Cygwin32.


Um, it's the same people.  Me. :)

Both packages are generated from the same source, with the same build 
options.  If they behave differently, it's likely because the SQLite 
code is doing something wrong with an ifdef, or because Cygwin itself 
behaves differently.

___
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] Random thoughts on Fossil v2

[Jacek Cała]

Hi All,

One more feature that I also miss in the current version is selective
commit. I mean something which allows you to see changes as a numbered list
and then commit selectively e.g. issuing 'fossil commit -range 1-10,15'. It
requires that 'fossil changes' is invoked before commit but that's what
users do I guess (at least me).

I find this feature very useful and it is very common in clients to SVN,
Mercurial, etc. And since fossil has embedded client, I'd really like to
see that as well.

Just to let you know, sometime ago I implemented that for myself as it
wasn't that difficult. It worked really nice, even if you changed file list
between 'fossil changes' and 'fossil commit...' calls by
removing/adding/modifying new files (then it just reported error like: 'run
fossil changes again'). One downside I remember was performance, for larger
commits it took much longer to run 'fossil commit' than 'fossil commit
-range xxx' even if a range was a subset of all changes. This was, however,
my simple, proof of concept implementation...

What do you think?
___
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] Scripting in Fossil v2

[Mark Janssen]

On Wed, Jul 24, 2013 at 12:37 PM, Stephan Beal wrote:

> On Wed, Jul 24, 2013 at 10:43 AM, Mark Janssen wrote:
>
>> I would just like to add that fossil already has a defined "API" in the
>> sense that what a fossil repo and server are is described in
>> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
>> http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say
>> that any truly useful fossil library should be built on those concepts.
>>
>
> i was recently wondering (haven't checked) whether the sync really belongs
> in the core lib or if networking is an app-level detail? The file
> format/manifest will (must) remain central to the design, and i started
> sketching out interfaces for working with the manifests.
>
> --
>

Synchronisation and authentication is definitely not a app-level detail for
a DVCS, the actual transport used could be though.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 1:15 PM, Jacek Cała  wrote:

> I find this feature very useful and it is very common in clients to SVN,
> Mercurial, etc. And since fossil has embedded client, I'd really like to
> see that as well.
>

That one's come up a few times - added to the list. A list member recently
(past 2 months or so) posted a mail with a shell script based on 'dialog'
which implements this. Searching isn't turning up it up, but the next time
my netbook is on i'll try to remember to send you a copy.


> Just to let you know, sometime ago I implemented that for myself as it
> wasn't that difficult. It worked really nice, even if you changed file list
> between 'fossil changes' and 'fossil commit...' calls by
> removing/adding/modifying new files (then it just reported error like: 'run
> fossil changes again'). One downside I remember was performance, for larger
> commits it took much longer to run 'fossil commit' than 'fossil commit
> -range xxx' even if a range was a subset of all changes. This was, however,
> my simple, proof of concept implementation...
>
> What do you think?
>

i'm trying not to think of such high-level features yet ;). i'm trying to
restrict my focus to basically anything which does not require user
interaction in order to work (interaction includes CLI flags, which are
handled app-level). Nonetheless, i've added this to the list, and can
envision multiple potential implementations (depending on the UI used). (It
might be fun to someday at a simple ncurses-based UI. (Did i really just
say that? "curses" is called that for a reason!))

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Baruch Burstein]

On Wed, Jul 24, 2013 at 2:00 PM, Stephan Beal  wrote:

> On Wed, Jul 24, 2013 at 9:38 AM, Edward Berner  wrote:
>
>> Personally, I'd vote for Fossil to remain C89.  Specifically I'd like
>> Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable
>> target.
>>
>
> As a matter of course, i never explicitly use any C99 features except for
> the 2 headers stdint.h and inttypes.h (for fixed-size integers and their
> portable printf/scanf modifiers) but those work just when compiling in c89
> mode, assuming your compiler has them. MSVC does not, but there are two
> open source projects offering drop-in replacements for these headers for
> MSVC. The current prototype code compiles with (-std=c89 -pedantic -Wall
> -Werror), but does use those two C99 headers.
>
> Why not use more modern features? I mean, I would probably not shift my
whole codebase to C++11 just yet, but writing new code using C99? Don't all
modern compilers support it already? If I was into really bad puns, I would
say that "Fossil" is just a name, not a goal.
I really am asking this out of interest why anyone would be against C99.
Having recently graduated and on my first job, I am very interested in what
seems to me to be completely irrational. In the past year I have found that
most "irrational" things are really just my lack of experience showing :-)

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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 Nijtmans]

2013/7/24 Warren Young 

>
> Just wait on the Cygwin64 people to bring out a new Sqlite package with
>> the same fixes already done in Cygwin32.
>>
>
> Um, it's the same people.  Me. :)
>
> Both packages are generated from the same source, with the same build
> options.  If they behave differently, it's likely because the SQLite code
> is doing something wrong with an ifdef, or because Cygwin itself behaves
> differently.
>
>
It looks like SQLite is doing something wrong here:
 
Of course, it was done for a good reason (cooperation
between Windows and Cygwin using the same sqlite
database), but now that that's fixed in Cygwin I think
that SQLite should be more UNIX-like on Cygwin.

Could you try that fix, please?

Regards,
   Jan Nijtmans
___
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] Scripting in Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 1:17 PM, Mark Janssen  wrote:

> Synchronisation and authentication is definitely not a app-level detail
> for a DVCS, the actual transport used could be though.
>

In fossil's case authentication is (currently) largely an app-level detail.
The core bits provide the basis of user+password+hashes+roles, but a large
portion of (the majority?) of the real auth-related code is very much
dependent on HTTP specifics. When running locally, without HTTP, you
effectively have no authentication. My point is only that yes, the lib has
to provided some basis for this, but much of the auth legwork is (at least
currently) happening at a higher level. My current thinking is that,
similar to now, the app is responsible for telling the library which user
it is acting on behalf of (which is actually only relevant in a minority of
cases - those which make db changes). The user ID/object would become part
of the parameters/state for any ops which require it (commit, wiki edit,
etc.).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] how to delete old history?

[Petr Pudlák]

Dear Fossil users,

I have a several year old project that has been managed in several VCS 
over its lifetime, and for past year or two it has been managed using 
Fossil. The history of the project contains some ancient code that is 
not necessary now, but worse, it also contains some ancient binary 
library files, which make the history quite large. Is there a way how to 
abandon some old code, for example to delete every commit that is older 
than some date?


I could export it to GIT, there make the change and import back, but 
this will change code commit hashes and therefore I'm not sure if it 
would be possible to keep the relations between tickets, commits and 
commit messages.


  Thank you,
  Petr Pudlak
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Wed, Jul 24, 2013 at 1:25 PM, Baruch Burstein wrote:

> Why not use more modern features? I mean, I would probably not shift my
> whole codebase to C++11 just yet, but writing new code using C99?
>

i tried that several times over the past years and (A) C99 doesn't provide
anything new which C89 is truly lacking except for portable fixed-sized
integers. It was vararrays and variadic macros, but i can't say i've ever
needed them. (B) MSVC has only minimal support for C99. It's sometimes
annoying to have to group all var decls in one place, but it's not a
feature which we need so badly that we should risk portability limitations
for it.

Don't all modern compilers support it already?
>

Most support the basic 2-3 features which so many rely on, e.g. //-style
comments and the ability to mix var decls and "code." MSVC's support is
reportedly spotty, but i recently read that their new round of compilers
(v2013?) has/will have full C99 support. tcc supports some parts of C99 but
not vararrays. 'long long' is available in most or all modern C89 compilers
("modern C89..." :-!), though it wasn't standardized until C99.

If I was into really bad puns, I would say that "Fossil" is just a name,
> not a goal.
>

LOL! Maybe that would be a good slogan for the project (it just occurred to
me that we don't have one).


> I really am asking this out of interest why anyone would be against C99.
> Having recently graduated and on my first job, I am very interested in what
> seems to me to be completely irrational. In the past year I have found that
> most "irrational" things are really just my lack of experience showing :-)
>

i'd be interested in hearing any arguments for C99 which can't also be done
(with comparable effort) in C89? i've _tried_ to find reasons to rely on
C99 in some code, but simply cannot find anything truly compelling, and
don't want to lose portability just in order to be able to mix var decls
and code.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Michai Ramakers]

Hi,

On 24 July 2013 13:25, Stephan Beal  wrote:
>>
>> I find this feature very useful and it is very common in clients to SVN,
>> Mercurial, etc. And since fossil has embedded client, I'd really like to see
>> that as well.
>
> That one's come up a few times - added to the list. A list member recently
> (past 2 months or so) posted a mail with a shell script based on 'dialog'
> which implements this. Searching isn't turning up it up, but the next time
> my netbook is on i'll try to remember to send you a copy.

that might have been me - don't bother searching, you type enough as
it is, recently ;) (but please continue)

Script is attached for reference, with minor changes w.r.t. last version.

Michai


fci
Description: Binary data
___
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 delete old history?

[Stephan Beal]

On Wed, Jul 24, 2013 at 1:36 PM, Petr Pudlák  wrote:

> Dear Fossil users,
>
> I have a several year old project that has been managed in several VCS
> over its lifetime, and for past year or two it has been managed using
> Fossil. The history of the project contains some ancient code that is not
> necessary now, but worse, it also contains some ancient binary library
> files, which make the history quite large. Is there a way how to abandon
> some old code, for example to delete every commit that is older than some
> date?
>

Nope. Fossil's data is, by design, immutable. There is a mechanism called
"shunning" to stop syncing of specific artifacts but that is intended for
cases like wrongly licensed data, security-relevant information, etc., and
is supposed to be a "last resort." It not the right tool for what you want
to do (fossil doesn't have a tool for that, by design).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 delete old history?

[Remigiusz Modrzejewski]

On Jul 24, 2013, at 13:36 , Petr Pudlák wrote:
> I have a several year old project that has been managed in several VCS over 
> its lifetime, and for past year or two it has been managed using Fossil. The 
> history of the project contains some ancient code that is not necessary now, 
> but worse, it also contains some ancient binary library files, which make the 
> history quite large. Is there a way how to abandon some old code, for example 
> to delete every commit that is older than some date?
> 
> I could export it to GIT, there make the change and import back, but this 
> will change code commit hashes and therefore I'm not sure if it would be 
> possible to keep the relations between tickets, commits and commit messages.


Exporting to git was my first idea.
If there are just a few of those big binary files, you can use shunning.
Otherwise, I guess you'll need to script something using fossil deconstruct, 
but I have no experience with that route.


Kind regards,
Remigiusz Modrzejewski



___
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 delete old history?

[Ramon Ribó]

Would it be interesting for fossil to have an export command to a new
fossil database, exporting only some changesets based on dates,
branches, etc?

This option would fix the requirement of another poster for deleting
old commits. It could be also an emergency solution for fossils where
people has commited by mistake big erroneous files or other ugly
material.

RR


2013/7/24 Remigiusz Modrzejewski :
>
> On Jul 24, 2013, at 13:36 , Petr Pudlák wrote:
>> I have a several year old project that has been managed in several VCS over 
>> its lifetime, and for past year or two it has been managed using Fossil. The 
>> history of the project contains some ancient code that is not necessary now, 
>> but worse, it also contains some ancient binary library files, which make 
>> the history quite large. Is there a way how to abandon some old code, for 
>> example to delete every commit that is older than some date?
>>
>> I could export it to GIT, there make the change and import back, but this 
>> will change code commit hashes and therefore I'm not sure if it would be 
>> possible to keep the relations between tickets, commits and commit messages.
>
>
> Exporting to git was my first idea.
> If there are just a few of those big binary files, you can use shunning.
> Otherwise, I guess you'll need to script something using fossil deconstruct, 
> but I have no experience with that route.
>
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Martin Gagnon]

Le 24 juil. 2013 06:06, "Lluís Batlle i Rossell"  a
écrit :
>
> On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> > 2013/7/24 Lluís Batlle i Rossell :
> > > I think our main usage for a cygwin fossil is that we develop using a
cygwin
> > > terminal with bash and vim. And we want fossil to spawn vim properly
on commit.
> >
> > That should work, only you should do something like:
> > export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> > I don't know vim enough to comment on that.
>
> Ah, the point isn't bash; the point is at processes passing properly the
fds
> for the *terminal*. I guess that once you put a non-cygwin process in the
family
> tree, the children can't access the terminal ancestor properly.
>

Have you try  gvim -f ? (Native windows GUI version of vim) so your comment
will not end by ':wq' :-)  like what could happens with notepad.

-- 
Martin G.
___
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 delete old history?

[Stephan Beal]

On Wed, Jul 24, 2013 at 2:02 PM, Ramon Ribó  wrote:

> Would it be interesting for fossil to have an export command to a new
> fossil database, exporting only some changesets based on dates,
> branches, etc?
>

That would be an extraordinarily complex process, i think, if it's even
really possible (while maintaining data integrity). The majority of
artifacts inherit from some parent artifact. If you remove any of these
relationships you've just broken the chain. "Maybe" fossil could re-link
the neighbors on either side of such a construct and recalculate deltas for
them. That sounds reasonable, but then comes syncing... what happens to
everyone else's copy of the repo which has those artifacts? We cannot
remove those artifacts from their copies because that would open up the
possibility for one malicious user to delete all content (irrevocably) from
all repos which sync with his. As one of the Ghostbusters famously said:
"That would be bad."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 delete old history?

[Ramon Ribó]

Of course, the new database would not be allowed to sync with the old
one. For all effects, it is a different database.

As for the complexity, I do not understand why it would be so complex.
You can do it now manually by executing a collection of "update" and
"commit". It would be just to automate this. Do not think in terms of
"artifacts", think on terms of "changesets".

RR


2013/7/24 Stephan Beal :
> On Wed, Jul 24, 2013 at 2:02 PM, Ramon Ribó  wrote:
>>
>> Would it be interesting for fossil to have an export command to a new
>> fossil database, exporting only some changesets based on dates,
>> branches, etc?
>
>
> That would be an extraordinarily complex process, i think, if it's even
> really possible (while maintaining data integrity). The majority of
> artifacts inherit from some parent artifact. If you remove any of these
> relationships you've just broken the chain. "Maybe" fossil could re-link the
> neighbors on either side of such a construct and recalculate deltas for
> them. That sounds reasonable, but then comes syncing... what happens to
> everyone else's copy of the repo which has those artifacts? We cannot remove
> those artifacts from their copies because that would open up the possibility
> for one malicious user to delete all content (irrevocably) from all repos
> which sync with his. As one of the Ghostbusters famously said: "That would
> be bad."
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to delete old history?

[Stephan Beal]

On Wed, Jul 24, 2013 at 2:18 PM, Ramon Ribó  wrote:

> As for the complexity, I do not understand why it would be so complex.
> You can do it now manually by executing a collection of "update" and
> "commit". It would be just to automate this. Do not think in terms of
> "artifacts", think on terms of "changesets".
>

"Complex" in terms of philosophical problems - is it "correct" to re-build
diffs between versions A and C if B is removed from between them, for
example. What do we do with tags and such which reference now-gone
artifacts? Remove them, orphan them, or flag them somehow has "stale"? What
is "The Right Thing" in such a case, and is it really The Right Thing for
every use case? Since syncing with existing copies would no longer be
possible after this change, this would seem to cause more problems than it
creates. Everyone would have to re-clone before continuing (which will
frustrate people and break automated processes which do pull/update, e.g.
for updating a web site's contents on a regular basis). The "bad"/old data
is still "out there" somewhere in other clones, so the problem has not been
solved. If you _really_ want to lose old history, simply create a new repo
and import your current project state into it. But even that doesn't really
"lose" it because some clone out there has it.

AFAIK git offers a mechanism for changing history, but Fossil doesn't like
for history to change.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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

[Lluís Batlle i Rossell]

On Wed, Jul 24, 2013 at 08:01:47AM -0400, Martin Gagnon wrote:
> Le 24 juil. 2013 06:06, "Lluís Batlle i Rossell"  a
> écrit :
> >
> > On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote:
> > > 2013/7/24 Lluís Batlle i Rossell :
> > > > I think our main usage for a cygwin fossil is that we develop using a
> cygwin
> > > > terminal with bash and vim. And we want fossil to spawn vim properly
> on commit.
> > >
> > > That should work, only you should do something like:
> > > export EDITOR="C:/Cygwin64/bin/bash.exe -c vim"
> > > I don't know vim enough to comment on that.
> >
> > Ah, the point isn't bash; the point is at processes passing properly the
> fds
> > for the *terminal*. I guess that once you put a non-cygwin process in the
> family
> > tree, the children can't access the terminal ancestor properly.
> >
> 
> Have you try  gvim -f ? (Native windows GUI version of vim) so your comment
> will not end by ':wq' :-)  like what could happens with notepad.

If I use windows with *all inside a cygwin terminal* is because I adapt very bad
to unusual environments. :)
___
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] Random thoughts on Fossil v2

[Jacek Cała]

Thanks for the script and am glad to hear that it's included.

  Best,
  Jacek


2013/7/24 Michai Ramakers 

> Hi,
>
> On 24 July 2013 13:25, Stephan Beal  wrote:
> >>
> >> I find this feature very useful and it is very common in clients to SVN,
> >> Mercurial, etc. And since fossil has embedded client, I'd really like
> to see
> >> that as well.
> >
> > That one's come up a few times - added to the list. A list member
> recently
> > (past 2 months or so) posted a mail with a shell script based on 'dialog'
> > which implements this. Searching isn't turning up it up, but the next
> time
> > my netbook is on i'll try to remember to send you a copy.
>
> that might have been me - don't bother searching, you type enough as
> it is, recently ;) (but please continue)
>
> Script is attached for reference, with minor changes w.r.t. last version.
>
> Michai
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to delete old history?

[Steve Landers]

On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:

> AFAIK git offers a mechanism for changing history, but Fossil doesn't like 
> for history to change.

It isn't changing history, it is setting a subproject free to live it's own 
life. That's not an unusual situation, given that projects often grow and then 
divide.

So I detach a local repository, rename it, and continue with a new repository 
for the subproject. But it contains all of the history for the parent project, 
as does the parent project repository.  I can push that to a branch and close 
it in the detached repo, no big deal.  But it isn't ideal, especially if the 
original repo is large. 

Being able to detach based on a specific commit or branch would be nice (not 
essential, but nice).

Steve
___
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 delete old history?

[Remigiusz Modrzejewski]

On Jul 24, 2013, at 16:21 , Steve Landers wrote:

> 
> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
> 
>> AFAIK git offers a mechanism for changing history, but Fossil doesn't like 
>> for history to change.
> 
> It isn't changing history, it is setting a subproject free to live it's own 
> life. That's not an unusual situation, given that projects often grow and 
> then divide.
> 
> So I detach a local repository, rename it, and continue with a new repository 
> for the subproject. But it contains all of the history for the parent 
> project, as does the parent project repository.  I can push that to a branch 
> and close it in the detached repo, no big deal.  But it isn't ideal, 
> especially if the original repo is large. 
> 
> Being able to detach based on a specific commit or branch would be nice (not 
> essential, but nice).

As well as being able to detach a particular directory in the checkout 
structure...


Kind regards,
Remigiusz Modrzejewski



___
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] Shared SSH account consideration.

[Andy Bradford]

Thus said Matt Welland on Thu, 18 Jul 2013 07:24:20 -0700:

> I see the ssh implementation as a possible stepping stone to something
> along the lines of gitolite for fossil.

It might also  be possible to come  up with anonymous SSH  access to the
system  so the  only  authentication required  would  come from  Fossil,
similar to how anoncvs works for OpenBSD:

http://www.openbsd.org/anoncvs.html#MIRROR

Andy
-- 
TAI64 timestamp: 400051efe49c


___
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] Random thoughts on Fossil v2

[Steve Landers]

On 24/07/2013, at 6:25 AM, Baruch Burstein  wrote:

> Having recently graduated and on my first job, I am very interested in what 
> seems to me to be completely irrational. In the past year I have found that 
> most "irrational" things are really just my lack of experience showing :-)

That is one of the more profound statements I've read recently, thanks :)

As a Tcl greybeard, let me point out that it supports IPv6, safe threading, 
coroutines, tailcalls/stackless, generators, very good internationalisation and 
localisation, easily embedded or you can embed C within it, event-driven I/O, a 
modern OO system (or you can choose the older, C++ style of OO), etc, etc.  And 
SQLite and Tcl/Tk itself show how good the test system is.

Just as Richard recently lamented the lower profile of the Unix pipes + 
processes programming model,  I also note the post-modern tendency to re-invent 
square wheels or assume solid + stable means outdated.  A good programmer 
should be willing to use multiple tools and languages, and that's not to say 
Ruby and Python and Lua and Haskell and others are without merit.  But when I 
need something that covers embedded to desktop to web,  and gives me a high 
level of productivity - well ... you know what my tool is :)

But again, thanks Baruch for your comment. I'm sure you'll go far in your 
career if you maintain that awareness :)

Steve

___
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] Shared SSH account consideration.

[Stephan Beal]

On Wed, Jul 24, 2013 at 4:28 PM, Andy Bradford wrote:

> It might also  be possible to come  up with anonymous SSH  access to the
> system  so the  only  authentication required  would  come from  Fossil,
> similar to how anoncvs works for OpenBSD:
>
> http://www.openbsd.org/anoncvs.html#MIRROR


This "probably" isn't what you want to do, but i think you could add
anonymous support by piping the /json/anonymousPassword and /json/login
calls through to manage the two-step authentication process for anonymous
users. That'd be an ugly way to do it, but it "should work."

e.g. pipe this to your remote

fossil json anonymousPassword

which results in something like:

{
"fossil":"1064dfac1221b19d1c0e29a1ad3615f7c75e153a",
"timestamp":1374677164,
"command":"anonymousPassword",
"procTimeUs":0,
"procTimeMs":0,
"payload":{
"seed":1223645593,
"password":"33f5ce7d"
}
}

That gives you the login info which you could then either send to the JSON
API or (since you're already going through HTTP) directly as HTTP form
data. You could keep the resulting authentication token cookie around a
while to avoid having to log in for each operation. The /json/login command
gives us the cookie's value as well.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] admin pages are empty and have bad titles

[Eric Rubin-Smith]

I think the point here is that with a baseurl of "https://foobar.com:10443/";,
certain links exposed by the fossil HTML generators wind up pointing my
browser to e.g. "https://foobar.com:10443//page_name";, with two slashes
after the port number.  And fossil's name resolution system does not squash
the two slashes -- there's a paged named "page_name" but none named
"/page_name".

Am I doing something wrong with my configs, or is a code change warranted?


On Tue, Jul 23, 2013 at 10:30 PM, Eric Rubin-Smith wrote:

> Yes, that works for the test case.  But I think I'll need --baseurl for
> when I put fossil behind an SSL-terminating reverse proxy and want to
> access it using the company FQDN.
>
>
> On Tue, Jul 23, 2013 at 10:22 PM, Andy Bradford <
> amb-sendok-1377224557.emjjjkijcgiknbipb...@bradfords.org> wrote:
>
>> Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400:
>>
>> > /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P
>> 10080
>> > --baseurl http://localhost:10080/
>>
>> Try removing the --baseurl option.
>>
>> It works for me when I do:
>>
>> fossil server /tmp/test.fossil
>>
>> ssh -L 10080:localhost:10080 remote
>>
>> Andy
>> --
>> TAI64 timestamp: 400051ef3a90
>>
>>
>>
>
___
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 delete old history?

[Isaac Jurado]

On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
 wrote:
>
> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
>
>> AFAIK git offers a mechanism for changing history, but Fossil doesn't like 
>> for history to change.
>
> It isn't changing history, it is setting a subproject free to live
> it's own life. That's not an unusual situation, given that projects
> often grow and then divide.
>
> So I detach a local repository, rename it, and continue with a new
> repository for the subproject. But it contains all of the history for
> the parent project, as does the parent project repository.  I can push
> that to a branch and close it in the detached repo, no big deal.  But
> it isn't ideal, especially if the original repo is large.
>
> Being able to detach based on a specific commit or branch would be
> nice (not essential, but nice).

That looks like a Fossil to Fossil export/import feature, without having
to go through Git fast-export format, right?

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Markdown

[djgoku]

Didn't read the change notes for 1.26 until a couple days ago. I just noticed 
that markdown is now turned on by default this is awesome!

Hopefully this will make it easier for my co-workers to start using it for 
documentation. I also see plain text option which is also awesome!

Thanks for everything!

Jonathan Otsuka
___
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 delete old history?

[Ramon Ribó]

Yes, that would be the idea, giving the possibility to define an
initial date, a branch selection, etc.

Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com  ram...@compassis.com
c/ Tuset, 8 7-2  tel. +34 93 218 19 89
08006 Barcelona, Spainfax. +34 93 396 97 46


2013/7/24 Isaac Jurado :
> On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
>  wrote:
>>
>> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
>>
>>> AFAIK git offers a mechanism for changing history, but Fossil doesn't like 
>>> for history to change.
>>
>> It isn't changing history, it is setting a subproject free to live
>> it's own life. That's not an unusual situation, given that projects
>> often grow and then divide.
>>
>> So I detach a local repository, rename it, and continue with a new
>> repository for the subproject. But it contains all of the history for
>> the parent project, as does the parent project repository.  I can push
>> that to a branch and close it in the detached repo, no big deal.  But
>> it isn't ideal, especially if the original repo is large.
>>
>> Being able to detach based on a specific commit or branch would be
>> nice (not essential, but nice).
>
> That looks like a Fossil to Fossil export/import feature, without having
> to go through Git fast-export format, right?
>
> --
> Isaac Jurado
>
> "The noblest pleasure is the joy of understanding"
> Leonardo da Vinci
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] admin pages are empty and have bad titles

[Mark Janssen]

What happens if you set base_url without trailing slash? e.g. "
https://foobar.com:10443";


On Wed, Jul 24, 2013 at 4:55 PM, Eric Rubin-Smith  wrote:

> I think the point here is that with a baseurl of "
> https://foobar.com:10443/";, certain links exposed by the fossil HTML
> generators wind up pointing my browser to e.g. "
> https://foobar.com:10443//page_name";, with two slashes after the port
> number.  And fossil's name resolution system does not squash the two
> slashes -- there's a paged named "page_name" but none named "/page_name".
>
> Am I doing something wrong with my configs, or is a code change warranted?
>
>
> On Tue, Jul 23, 2013 at 10:30 PM, Eric Rubin-Smith wrote:
>
>> Yes, that works for the test case.  But I think I'll need --baseurl for
>> when I put fossil behind an SSL-terminating reverse proxy and want to
>> access it using the company FQDN.
>>
>>
>> On Tue, Jul 23, 2013 at 10:22 PM, Andy Bradford <
>> amb-sendok-1377224557.emjjjkijcgiknbipb...@bradfords.org> wrote:
>>
>>> Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400:
>>>
>>> > /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P
>>> 10080
>>> > --baseurl http://localhost:10080/
>>>
>>> Try removing the --baseurl option.
>>>
>>> It works for me when I do:
>>>
>>> fossil server /tmp/test.fossil
>>>
>>> ssh -L 10080:localhost:10080 remote
>>>
>>> Andy
>>> --
>>> TAI64 timestamp: 400051ef3a90
>>>
>>>
>>>
>>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] how to delete old history?

[sky5walk]

>From my Fossil cheat sheet...regarding this mail thread:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg09584.html
-
fossil shunning or deleting files permanently.
-
Use the Admin - Shun page on fossil ui.
Then enter the full SHA1 of the artifact to delete.
Then use c:\myrepo>fossil rebuild --vacuum
(The ui button did not work.)

These deletions are only seen on the LOCAL repo and must be push|pull'ed
manually.
c:\myrepo>fossil config push shun \\mynetwork\myrepo.fossil
c:\myrepo>fossil config pull shun \\mynetwork\myrepo.fossil

Thanks for Fossil!

On Wed, Jul 24, 2013 at 11:50 AM, Ramon Ribó  wrote:

> Yes, that would be the idea, giving the possibility to define an
> initial date, a branch selection, etc.
> 
> Compass Ing. y Sistemas Dr. Ramon Ribo
> http://www.compassis.com  ram...@compassis.com
> c/ Tuset, 8 7-2  tel. +34 93 218 19 89
> 08006 Barcelona, Spainfax. +34 93 396 97 46
>
>
> 2013/7/24 Isaac Jurado :
> > On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
> >  wrote:
> >>
> >> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
> >>
> >>> AFAIK git offers a mechanism for changing history, but Fossil doesn't
> like for history to change.
> >>
> >> It isn't changing history, it is setting a subproject free to live
> >> it's own life. That's not an unusual situation, given that projects
> >> often grow and then divide.
> >>
> >> So I detach a local repository, rename it, and continue with a new
> >> repository for the subproject. But it contains all of the history for
> >> the parent project, as does the parent project repository.  I can push
> >> that to a branch and close it in the detached repo, no big deal.  But
> >> it isn't ideal, especially if the original repo is large.
> >>
> >> Being able to detach based on a specific commit or branch would be
> >> nice (not essential, but nice).
> >
> > That looks like a Fossil to Fossil export/import feature, without having
> > to go through Git fast-export format, right?
> >
> > --
> > Isaac Jurado
> >
> > "The noblest pleasure is the joy of understanding"
> > Leonardo da Vinci
> > ___
> > 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] admin pages are empty and have bad titles

[Eric Rubin-Smith]

I don't even get past the args parsing phase if I try that:

[fossil@monk ~]$ /usr/local/bin/fossil server /home/fossil/repo.fossil -P
10080 --baseurl https://mysite.com:10443
argument to --baseurl should be 'http://host/path' or 'https://host/path'
[fossil@monk ~]$




On Wed, Jul 24, 2013 at 11:55 AM, Mark Janssen wrote:

> What happens if you set base_url without trailing slash? e.g. "
> https://foobar.com:10443";
>
>
> On Wed, Jul 24, 2013 at 4:55 PM, Eric Rubin-Smith wrote:
>
>> I think the point here is that with a baseurl of "
>> https://foobar.com:10443/";, certain links exposed by the fossil HTML
>> generators wind up pointing my browser to e.g. "
>> https://foobar.com:10443//page_name";, with two slashes after the port
>> number.  And fossil's name resolution system does not squash the two
>> slashes -- there's a paged named "page_name" but none named "/page_name".
>>
>> Am I doing something wrong with my configs, or is a code change warranted?
>>
>>
>> On Tue, Jul 23, 2013 at 10:30 PM, Eric Rubin-Smith wrote:
>>
>>> Yes, that works for the test case.  But I think I'll need --baseurl for
>>> when I put fossil behind an SSL-terminating reverse proxy and want to
>>> access it using the company FQDN.
>>>
>>>
>>> On Tue, Jul 23, 2013 at 10:22 PM, Andy Bradford <
>>> amb-sendok-1377224557.emjjjkijcgiknbipb...@bradfords.org> wrote:
>>>
 Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400:

 > /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P
 10080
 > --baseurl http://localhost:10080/

 Try removing the --baseurl option.

 It works for me when I do:

 fossil server /tmp/test.fossil

 ssh -L 10080:localhost:10080 remote

 Andy
 --
 TAI64 timestamp: 400051ef3a90



>>>
>>
>> ___
>> 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 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 delete old history?

[Steve Landers]

On 24/07/2013, at 11:06 AM, sky5w...@gmail.com wrote:

> From my Fossil cheat sheet...regarding this mail thread:
> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg09584.html
> -
> fossil shunning or deleting files permanently.
> -
> Use the Admin - Shun page on fossil ui.
> Then enter the full SHA1 of the artifact to delete.
> Then use c:\myrepo>fossil rebuild --vacuum
> (The ui button did not work.)
> 
> These deletions are only seen on the LOCAL repo and must be push|pull'ed 
> manually.
> c:\myrepo>fossil config push shun \\mynetwork\myrepo.fossil
> c:\myrepo>fossil config pull shun \\mynetwork\myrepo.fossil

It not practical to individually manually shun each unwanted artifact thru the 
web interface.

 --Steve

On Wed, Jul 24, 2013 at 11:50 AM, Ramon Ribó  wrote:
> Yes, that would be the idea, giving the possibility to define an
> initial date, a branch selection, etc.
> 
> Compass Ing. y Sistemas Dr. Ramon Ribo
> http://www.compassis.com  ram...@compassis.com
> c/ Tuset, 8 7-2  tel. +34 93 218 19 89
> 08006 Barcelona, Spainfax. +34 93 396 97 46
> 
> 
> 2013/7/24 Isaac Jurado :
> > On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
> >  wrote:
> >>
> >> On 24/07/2013, at 7:28 AM, Stephan Beal  wrote:
> >>
> >>> AFAIK git offers a mechanism for changing history, but Fossil doesn't 
> >>> like for history to change.
> >>
> >> It isn't changing history, it is setting a subproject free to live
> >> it's own life. That's not an unusual situation, given that projects
> >> often grow and then divide.
> >>
> >> So I detach a local repository, rename it, and continue with a new
> >> repository for the subproject. But it contains all of the history for
> >> the parent project, as does the parent project repository.  I can push
> >> that to a branch and close it in the detached repo, no big deal.  But
> >> it isn't ideal, especially if the original repo is large.
> >>
> >> Being able to detach based on a specific commit or branch would be
> >> nice (not essential, but nice).
> >
> > That looks like a Fossil to Fossil export/import feature, without having
> > to go through Git fast-export format, right?
> >
> > --
> > Isaac Jurado
> >
> > "The noblest pleasure is the joy of understanding"
> > Leonardo da Vinci
> > ___
> > 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 mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

Re: [fossil-users] how to delete old history?

[sky5walk]

True, that was already discussed in the attached thread.
Some mentioned SQL dumps of artifacts, or you could open your repo in a
SQLite browser to get the list.
But, at least it works.
Automating shuns is high on my list too!
At least enable the cmd via fossil.exe and not just the ui?


On Wed, Jul 24, 2013 at 12:18 PM, Steve Landers
wrote:

>
> On 24/07/2013, at 11:06 AM, sky5w...@gmail.com wrote:
>
> > From my Fossil cheat sheet...regarding this mail thread:
> >
> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg09584.html
> > -
> > fossil shunning or deleting files permanently.
> > -
> > Use the Admin - Shun page on fossil ui.
> > Then enter the full SHA1 of the artifact to delete.
> > Then use c:\myrepo>fossil rebuild --vacuum
> > (The ui button did not work.)
> >
> > These deletions are only seen on the LOCAL repo and must be push|pull'ed
> manually.
> > c:\myrepo>fossil config push shun \\mynetwork\myrepo.fossil
> > c:\myrepo>fossil config pull shun \\mynetwork\myrepo.fossil
>
> It not practical to individually manually shun each unwanted artifact thru
> the web interface.
>
>  --Steve
>
> On Wed, Jul 24, 2013 at 11:50 AM, Ramon Ribó  wrote:
> > Yes, that would be the idea, giving the possibility to define an
> > initial date, a branch selection, etc.
> > 
> > Compass Ing. y Sistemas Dr. Ramon Ribo
> > http://www.compassis.com  ram...@compassis.com
> > c/ Tuset, 8 7-2  tel. +34 93 218 19 89
> > 08006 Barcelona, Spainfax. +34 93 396 97 46
> >
> >
> > 2013/7/24 Isaac Jurado :
> > > On Wed, Jul 24, 2013 at 4:21 PM, Steve Landers
> > >  wrote:
> > >>
> > >> On 24/07/2013, at 7:28 AM, Stephan Beal 
> wrote:
> > >>
> > >>> AFAIK git offers a mechanism for changing history, but Fossil
> doesn't like for history to change.
> > >>
> > >> It isn't changing history, it is setting a subproject free to live
> > >> it's own life. That's not an unusual situation, given that projects
> > >> often grow and then divide.
> > >>
> > >> So I detach a local repository, rename it, and continue with a new
> > >> repository for the subproject. But it contains all of the history for
> > >> the parent project, as does the parent project repository.  I can push
> > >> that to a branch and close it in the detached repo, no big deal.  But
> > >> it isn't ideal, especially if the original repo is large.
> > >>
> > >> Being able to detach based on a specific commit or branch would be
> > >> nice (not essential, but nice).
> > >
> > > That looks like a Fossil to Fossil export/import feature, without
> having
> > > to go through Git fast-export format, right?
> > >
> > > --
> > > Isaac Jurado
> > >
> > > "The noblest pleasure is the joy of understanding"
> > > Leonardo da Vinci
> > > ___
> > > 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 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Random thoughts on Fossil v2 - translations

[fvd]

For a while I had been meaning to share the configuration file for a 
Spanish translation to the list. You can find it here:


   http://versions.southshield.net/fossiles/index

And this also serves as an illustration of what I wrote to Stephan Beal 
earlier with perhaps some additions about what would be nice for V2:


1. The configuration files have some odd behaviour. Take the 
fossilES.config as an example. It contains multiple ^M characters, but 
cleaning those up (either by fossil or with vim) renders the 
configuration file useless. Diff will show the files to be identical, 
but it simply will no longer load using fossil configuration if the ^M 
characters are removed.


2. The configuration file could be more readable, for instance by 
adding sections (with commented section headers for instance) so that it 
is easier to go through them and make changes.


3. Not all strings in the HTML interface can be translated. Especially 
for the instructions in the UI this would be really helpful if these 
could be translated (for instance in the config file). Take as an 
example the text on the /login page, or the /brlist page.


4. I see no need to change anything in the language used for the 
command line and help, but the great thing of fossil is that it allows 
for an online (HTML) UI that can be offered to non-programmers. I would 
help a lot if everything there can be subject to internationalization.


Having better support for languages in the HMTL interface will - I 
believe - increase the user base of fossil. It is so incredibly useful 
to have ticketing included in environments where internet access is not 
a given or not reliable!


___
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

[Warren Young]

On 7/24/2013 05:30, Jan Nijtmans wrote:


It looks like SQLite is doing something wrong here:
  


That patch is fine on Cygwin as long as you build Fossil with the 
external SQLite, rather than the bundled SQLite.


The bundled SQLite is almost certainly broken with that patch because it 
probably isn't using the Cygwin 1.7.20+ F_LCK_MANDATORY feature, so it 
won't cooperate properly with any program based on native Windows SQLite.


(And if stock Fossil does turn on mandatory locking on Cygwin via the 
new Cygwin feature, they also need to add a way to turn it *off*, as 
Cygwin SQLite does with CYGWIN_SQLITE_LOCKING=posix, else the program 
won't be able to cooperate with other programs based on Cygwin SQLite.)



Could you try that fix, please?


What exactly are you asking me to do here?

I've already indicated that I'm going to wait until 3.7.18 comes out to 
see if they've fixed the backslash problem, and if they haven't, hack 
around it in Cygwin SQLite.  That still requires you to build Fossil 
with the system SQLite to get my fixes.


I don't have checkin rights on either Fossil or SQLite core, so if you 
want the stock distributed version changed in some way, you're better 
off asking one of the core developers.

___
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] mingw and default ssh command

[Martin Gagnon]

On Wed, Jul 24, 2013 at 12:35:51AM -0600, Andy Bradford wrote:
> Thus said Martin Gagnon on Tue, 23 Jul 2013 22:37:27 -0400:
> 
> > I guess when we want to sync with another url, we should have a chance
> > to specify user again (user may be different on the another repo), and
> > it should save the  new default user to the checkout  db, the same way
> > the remote-url is saved.
> 
> Ok, I think I have made some decent progress here:
> 
> http://www.fossil-scm.org/index.html/info/955b39ee9f
> 
> Please try it out if you get a chance.
> 
> I added  the suppressed SSH  output that you  suggested. I have  not yet
> dealt with the --once option... that  will have to wait for another day.
> :-)
> 
> As always, your feedback is appreciated.
> 
> Thanks,

I tried this new version today. There is an improvement in sync terminal
output. But it seems that now, if I have a user in the URL and a -l
 argument, the user from the URL is used for the fossil
authentifcation. (It was not the case on previous version I tried..)

Regards, 

-- 
Martin G.
___
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] mingw and default ssh command

[Andy Bradford]

Thus said Martin Gagnon on Wed, 24 Jul 2013 20:44:05 -0400:

> I  tried this  new  version today.  There is  an  improvement in  sync
> terminal output. But  it seems that now,  if I have a user  in the URL
> and a -l  argument, the user from the URL is used for the fossil
> authentifcation. (It was not the case on previous version I tried..)

Yes,  it  was  working  in  the previous  version.  Apparently  I  broke
something since then, it's not behaving:

$ fossil clone -l guest ssh://amb@remote//tmp/new.fossil clone.fossil
password for amb: 

Bad!

I'll take a look at it.

Thanks,

Andy
-- 
TAI64 timestamp: 400051f08104


___
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] mingw and default ssh command

[Andy Bradford]

Thus said Martin Gagnon on Wed, 24 Jul 2013 20:44:05 -0400:

> But  it seems  that  now,  if I  have  a  user in  the  URL  and a  -l
>   argument,  the user  from  the  URL  is  used for  the  fossil
> authentifcation.

Thanks for pointing it out:

http://www.fossil-scm.org/index.html/info/90ee2ee528

Let me know if you notice anything else.

There is  one thing which  needs some work if  possible. If you  are not
using SSH keys, the  prompt for your SSH password ends up  on top of the
Round-trips status line:

$ fossil clone -l guest ssh://amb@remote//tmp/new.fossil clone.fossil
password for guest: 
remember password (Y/n)? y
Round-trips: 1   Artifacts sent: 0  received: 0
ssh -e none -T amb@remote fossil http /tmp/new.fossil
amb@remote's password: 
amb@remote's password: cts sent: 0  received: 1
Round-trips: 2   Artifacts sent: 0  received: 3
Clone finished with 546 bytes sent, 1157 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: c0963fbe84473812993cee1f46d6ce6eb890c05f
admin-user: amb (password is "63231d")

This is because the SSH prompt is writing on top of the Round-trips line
which doesn't include  a newline. Of course this isn't  present if there
is no  authentication required  (SSH keys  in use  with ssh-agent  or no
passphrase on key,  or in the case of an  anonymous SSH fossil account),
and so it looks nicer.

I'll take a  look, but I'm not  sure there is anything that  can be done
about the  case where it  prompts for  a password, but  it can be  a bit
confusing  to see  the password  prompt  mixed in  with the  Rount-trips
output.

Thanks,

Andy
-- 
TAI64 timestamp: 400051f086da


___
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] admin pages are empty and have bad titles

[Andy Bradford]

Thus said Eric Rubin-Smith on Wed, 24 Jul 2013 10:55:24 -0400:

> Am  I doing  something wrong  with  my configs,  or is  a code  change
> warranted?

That's hard to say since I don't know under what conditions --baseurl is
intended to be  used (I know the  docs say reverse proxy,  but I haven't
ever set  one up so  I don't understand all  the fine details).  The one
time I tried to use it, I was  doing it wrong:

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12107.html

In my case,  however, I was using ``fossil http''  not ``fossil server''
and when I got rid of the --baseurl option, things worked as expected.

In your case,  you are trying to  setup a reverse proxy...  if you could
provide some  details about  to setup  a reverse  proxy similar  to your
configuration (perhaps it  is done with Apache), it might  be easier for
someone to reproduce.

Have you tried using it without --baseurl?  If so, what happened?

Thanks,

Andy
-- 
TAI64 timestamp: 400051f08852


___
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] Shared SSH account consideration.

[Andy Bradford]

Thus said Stephan Beal on Wed, 24 Jul 2013 16:51:07 +0200:

> This  "probably" isn't  what you  want to  do, but  i think  you could
> add  anonymous  support  by  piping  the  /json/anonymousPassword  and
> /json/login  calls  through  to  manage  the  two-step  authentication
> process for anonymous  users. That'd be an  ugly way to do  it, but it
> "should work."

I think I need to understand  how ``anonymous'' works (not to mention my
lack of  fossil json knowledge) before  I'll be able to  say for certain
which method would work with SSH.

Anonymous SSH fossil access was just a thought that occurred to me and I
wanted to share to see if there  was any interest. Most of the setup for
it is likely outside the scope  of fossil. Basically it involves setting
up a passwordless SSH account (perhaps named anonfsl) that when used has
a  ForceCommand  that  runs  a  special shell  (possibly  in  a  chroot)
which  will  simply setup  a  fossil  http  with the  requested  fossil.
At  that  point, fossil  authentication  would  do the  rest  (including
anonymous/nobody access).

Thanks for the suggestion.

Andy
--
TAI64 timestamp: 400051f0c19c
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users