Re: [fossil-users] [GitLab, Inc.] Update: GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

[Konstantin Khomoutov]

On Tue, 28 Mar 2017 00:33:02 +
"Matija Čupić (GitLab, Inc.)"  wrote:

> > > > http://esr.ibiblio.org/?p=7448
> > > > http://www.catb.org/esr/src/
> > > 
> > > Thanks for pointing this out, Stephan.
> > > 
> > > What intrigues me most here is not ESR's python-script wrapper
> > > around RCS/SCCS, but rather the GitLab interface.  I had heard of
> > > GitLab, but had never before taken the time to look into it.  My
> > > first impression is that it seems much nicer than GitHub.
> > [...]
> > 
> > JFTR GitLab is written in Ruby, so it's not at all self-hosting.
> > Fossil has a clear upper hand in this.

> Yup, it's in Ruby. That doesn't relate to it being self-hostable or
> not, at all.

I meant self-hosting in the sense Fossil folks understand it: Fossil
comes in the form of a single executable file (possibly even statically
linked) which you can drop anywhere, run `fossil serve` and be done with
it.  That same binary also hosts its own web UI through running
`fossil ui`.  Of course, the same binary also performs its "regular"
SCM tasks.

These days, different communities overloaded the term "self-hosted" to
mean a whole range of things including "we have a Docker container with
it". ;-)  Sure, possibly those are valid overloadings but I meant
"self-hosting" in a very narrow primordial sense.

If I'm wrong on this and GitLab indeed may be used in the form of a
single executable enabled for the so-called "xcopy deployment" then
please excuse me for spreading FUD and I'm OK with standing
corrected ;-)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

[Konstantin Khomoutov]

On Sun, 26 Mar 2017 13:18:08 -0400
Richard Hipp  wrote:

> > http://esr.ibiblio.org/?p=7448
> > http://www.catb.org/esr/src/
> 
> Thanks for pointing this out, Stephan.
> 
> What intrigues me most here is not ESR's python-script wrapper around
> RCS/SCCS, but rather the GitLab interface.  I had heard of GitLab, but
> had never before taken the time to look into it.  My first impression
> is that it seems much nicer than GitHub.
[...]

JFTR GitLab is written in Ruby, so it's not at all self-hosting.
Fossil has a clear upper hand in this.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Git just got shallow and sparse clones

[Konstantin Khomoutov]

On Fri, 3 Feb 2017 09:00:54 -0700
Warren Young  wrote:

> https://developers.slashdot.org/story/17/02/03/1427213/microsoft-introduces-gvfs-git-virtual-file-system

Care to elaborate a bit?

commit 016e6ccbe03438454777e43dd73d67844296a3fd
Author: Johannes Schindelin 
Date:   Mon Oct 30 20:09:29 2006 +0100

allow cloning a repository "shallowly"

Available since v1.5.

commit ed5336a7541e19b267de53afc8d15cffdbde8286
Author: Nguyễn Thái Ngọc Duy 
Date:   Thu Aug 20 20:47:05 2009 +0700

Introduce "sparse checkout"

Available since v1.7.

The current stable Git version is 2.11.
___
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

[Konstantin Khomoutov]

On Mon, 10 Oct 2016 14:49:55 -0300
Richie Adler  wrote:

[...]
> Fossil is a perfect example of an excuse that has to die. *Nobody*
> has the excuse that version control is costly or complicated anymore.
> You don't even need to create an account in Github.

So, do you really think one has to create a Github account to use Git?
You have been sadly misinformed then: github.com is to Git what
chiselapp.com is to Fossil -- a hosting solution (one of many, in case
of Git).

> You can keep it all in house and the configuration couldn't be
> easier...

You can "keep it all in house" using any contemporary VCS.

That's not to say Fossil does not have some edge here in the form of
its cobmo -- self-hosting on the server plus easy web UI -- just please
be objective.
Say, if I need to back a Git repo up to a nearby server I do

  ssh server git init --bare ~/repo.git
  git remote add backup ssh://server/~/repo.git
  git push --all --follow-tags backup

which, I reckon, is next to be zero-configuration, too.
___
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] Files named "AUX" on Windows

[Konstantin Khomoutov]

On Wed, 5 Oct 2016 09:37:23 -0600
Warren Young  wrote:

[...]
> 2. Contrast almost every Unix system, where the only illegal
> character in a file name is the forward slash.

...and NUL, I beleive.

[...]
___
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] Sing a song of praise for git {retch}

[Konstantin Khomoutov]

On Wed, 18 May 2016 13:12:30 -0600
Scott Robison  wrote:

[...]
> Yes, I dislike git (though TortoiseGit makes it a lot more
> tolerable). I don't blame guns when people get shot, or knives when
> people get stabbed, or cars or alcohol when someone dies in a drunk
> driving accident. The fact that git has a rebase command doesn't
> appeal to me, but if other people want to "fix" their history before
> publishing it, fine. But once it is published leave it the hell alone!
[...]

When you record a commit, you might be introducing an error in the
project.  So let's not have the "commit" feature in our VC tools.

The fact there are morons among your technical staff is unfortunate
(and I sympathize you on this) but this has nothing to do with Git.
___
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] Conversation with a CM guy

[Konstantin Khomoutov]

On Mon, 16 May 2016 23:06:59 -0500
Andy Goth  wrote:

> > He said he thinks he'll go with Git instead because that would give
> > the engineers working under him more forward mobility when they
> > eventually move on to other companies, whereas Fossil is unknown
> > and would not improve their employability.
> >
> > [...]
> >
> > Of course, none of that matters since he started by prioritizing
> > marketing.
> 
> I had a thought about Git marketing versus Fossil marketing.
> 
> Git's success, at least its initial adoption from which critical mass
> formed, is due to it being written by the principal author of Linux
> for managing the development of Linux.

I think its an overestimation.  Don't forget that the landscape of
F/OSS VC systems was different back then.  In reality, DVC systems
existing around year 2005 were either slow (Monotone, Darcs) or had
horrible UI (GNU Arch) so Torvalds had nothing to pick from.

> Sound familiar?
> 
> Fossil was written by the principal author of SQLite for managing the
> development of SQLite, and SQLite is arguably MORE successful than
> Linux, so... haha.
> 
> But then I'm reminded of drh speaking at the 2012 Tcl/Tk Conference,
> showing a chart correlating a massive jump in Apple stock with Apple's
> adoption of SQLite.  He said this to demonstrate his claimed inability
> to market his products, because he's not been able to use this chart
> to sway any management types.  (Am I remembering that correctly?)

In my opinion the best marketing strategy for Fossil would be to
compete with Subversion as trying to be a safe go-to solution for shops
with "simple" demands.  I think the statements made by one of
Subversion developers in his «Version Control and “the 80%”» rant [1]
pretty much explain why those who like Git won't switch to Fossil but
how a simpler solution could help "the 80%" to cope with version
control.

Unfortunately, the major selling points of Subversion -- excellent
Windows support including (proprietary) server-side solution with GUI
configurator and TotroiseSVN -- do not exist for Fossil.  Or at least
they are not visible well enough.

And ways to integrate Fossil to popular solutions like MSVS and Visual
Studio Code appear to be of increasing relevance to me (I mean, more
and more people with simple demands appear to use VC right from their
IDEs).

1. http://blog.red-bean.com/sussman/?p=79
___
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 discussion over at HN

[Konstantin Khomoutov]

On Tue, 5 Apr 2016 11:58:45 -0400
Richard Hipp  wrote:

> > To recap, centralization has both its pros and cons, and this has
> > nothing to do with particulars of DVCSes.
> 
> No, the DVCS does impact on this.
> 
> You can self-host using Git just as you can with Fossil.  The point is
> that setting up a self-hosting site for Fossil is *much* easier than
> it is with Git.
> 
> A key reason for the success of GitHub is that they make using Git
> easy.  Without GitHub (or something like that) Git is sufficiently
> difficult to configure into a development site, and to maintain, that
> most people wouldn't bother.
> 
> Fossil significantly lowers the barrier to entry for self-hosters.

Turn-key solutions for Git do exist (see [1] for instance) but setting
up a Fossil server is indeed way simpler -- unless you're an
organization, of course, where it doesn't really matter.

1. https://news.ycombinator.com/item?id=11429039
___
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 discussion over at HN

[Konstantin Khomoutov]

On Tue, 5 Apr 2016 09:34:34 -0400
Richard Hipp  wrote:

> GitHub has apparently suffered another outage.  Fossil comes up a lot
> in the resulting discussion over on Hacker News
> (https://news.ycombinator.com/item?id=11428776).  I didn't read it
> all, but most comments seem positive.

I know I will state the obvious thing but Git != Github.

To my knowledge, Fossil currently has the single hosting solution
available: chiselapp.com; should it have had its outage, the
repercussions for its users would be roughly the same.

Sure, the canned answer to this claim is that self-hosting with Fossil
is super-easy but

1) Hosting on Github (or any other such solution) is, and will always
   be, easier.
   I mean, it's indeed simple to roll your own Fossil server, but
   it's still easier to register with a go-to service and click through
   some sort of "create me a repo" wizard.

2) People host on Github not because they have to but because
   it's readily accessible to a wide audience (everyone has a Github
   account).
   I mean, it's a purely social thing which has nothing to do with
   peculiarities of different DVCS-es.

And please also consider the reverse problem.  Suppose I decided to
self-host my repos.  So I rented a VPS, made Fossil up and running there
and started to host some project there, which gained some popularity.
Then I lost interest and that VPS got its support terminated and went
offline.  Sure, since it's a DVCS, some folks will have backup repos,
but then there's this problem of resurrecting the stuff back.  With a
well-visible hoster like Github, someone will merely fork my repo and
start caring about it.  Everyone will be able to see what have happened
using that "network" feature of the Github web UI, which basically
allows to see which clones are more recent.

To recap, centralization has both its pros and cons, and this has
nothing to do with particulars of DVCSes.
___
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 mentioned on HN

[Konstantin Khomoutov]

On Wed, 16 Dec 2015 14:28:39 -0700
Scott Robison  wrote:

[...]
> I realize that 'get rebase -i' gives a lot more tools, but couldn't
> 99% of rebase use cases be handled with private branches?

`git rebase` is about rewriting history.  It has several modes of
operation (that is, it can be used for tasks different from its
original intent -- rebasing -- such as squashing several commits
together, editing a commit, splitting commits, deleting commit etc) but
no matter what mode `git rebase` is being used in, it rewrites
(recreates) commits.

If a VCS assumes the dogma of never touching a commit once it's created,
it can't have rebase-like functionality.

On the other hand, whatever is being said here about having rebasing
in Git is mostly religious bs: any sensible Git user knows that
you never rebase what you already pushed to a repo accessible by anyone
other than whoever did that push.  So if the talk is about not touching
the sacred history on a branch but rather creating another (private)
branch and recreating some of the original work there differently
(through using cherry pick etc) then yes, it's almost like rebasing,
just less convenient to use.

And there's another problem: say, if I support a pile of code I intend
to eventually submit upstream on a dedicated branch (a typical case for
"classic" rebasing) I do periodic synchronization with upstream by
pulling in their changes and replaying my changes on top of theirs.
Each time after this act I have a changed branch, and I want to push it
somewhere (to another maching I work at, for instance), and to support
that, the VCS has to 1) allow me to do that; 2) support "forced
pushing" where I explicitly tell it I want to overwrite a remote branch
with the branch I'm pushing.  IIUC, Fossil's private branches as of now
don't quite cut it because they don't support the points above.
Hence to me, private branches look more like what's known in some VCS
systems as "shelving": a possibiliy to keep some bits uncommitted/not
sent to a rendez-vous repo.
___
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] Is fossil export known to be broken?

[Konstantin Khomoutov]

On Sat, 12 Dec 2015 08:42:48 -0500
Richard Hipp  wrote:

> > It seems that somebody else ran into this at the start of the year:
> > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19238.html
> Yeah, that's a bummer.
> 
> Part of the problem stems from the fact that the Git fast-export
> format is only sparsely documented, and in some cases incorrectly
> documented.  And Git is very fussy about the format.  So it is
> possible to generate a fast-export file that conforms exactly to the
> documentation but which Git will not accept.  And since Git is the
> dominant VCS at the moment, the Git people are under no pressure to
> fix this sad state of affairs.

Did you report a bug?

It's just a matter of posting a mail to git at vger.kernel.org;
subscription is not required.
___
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] VCS Theory

[Konstantin Khomoutov]

On Thu, 19 Nov 2015 11:51:41 -0800
Scott Doctor  wrote:

> I am looking for information about the theory of VCS that is 
> being used for systems such as Fossil, Git... Not so much the 
> how-to-use, but the concepts and issues.
> 
> Any suggestions of either links to something like wikipedia 
> pages or a well written book I can find at the university library.

I'd honestly start with "The Git Parable" [1].  It's very entry-level
graceful introduction to the core ideas behind a DVCS, and it's not
really Git-specific.
Then you may consider reading [2].  This text *is* Git-specific but
the basic idea of data handling is delivered rather well.

1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
2. https://jwiegley.github.io/git-from-the-bottom-up/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] xkcd on git

[Konstantin Khomoutov]

On Sat, 31 Oct 2015 09:53:52 +0100
Stephan Beal  wrote:

> > Unless you delete .git your checkout is always in well defined
> > state.
> No, it's not. i once literally had one of the libgit maintainers at
> my desk for a full hour trying to get my repo (of a project we were
> both working on for our employers) back in a pushable state after it
> got jumbled up by me copy/pasting commands suggested by StackOverflow
> (about the worst place to get git advice). If one of the developers
> takes that long to straighten it out, then something is (IMO)
> fundamentally wrong.

That's still barking at the wrong tree.

You're unlikely to screw up a Fossil repo *that* much by
mindlessly copying-and-pasting something from SO but that's because
Fossil simply does not expose commands which allow you do perform
intricate surgeries on your repo.  To perform such fine operations, you
have to be trained at them or just abstrain from doing them.  Or at
least try them in a sandbox first.  It's like you being able to
actually disassemble your car and them have a skilled technician
assemble it back again because you have no idea how to do that.

Sure, not everyone wants to be able to perform low-level operation on
their repos, and not everyone wants to have the necessary skills.
That's absolutely OK, but claiming that that not having tools to do that
is somehow superior to another approach appears to be perfectly the same
as fanboyism of those praising the products originating from a
well-known company headquartered at Cupertino. :-)

All-in-all, I'm afraid the thread got quickly derailed from the
original problem: present DVCSs are known to suck at delivering
simple and understandable concepts to "mere mortals".
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] xkcd on git

[Konstantin Khomoutov]

On Fri, 30 Oct 2015 10:56:48 -0700
Scott Doctor  wrote:

> That is my experience with all VCS systems. Even with fossil, I 
> am having trouble justifying why the hassle is worth the effort.

I'm honestly not flame-baiting but have you tried to come up with an
interface idea/sketch/set of paradigms that would considerably lower
the barrier for people to use DVC systems?

No, really, even those rare programmers who are able to reason about
the ways their software is used like "mere mortals" are skewed in their
reasoning.

I'm a programmer, and after having used a bunch of centralized and
distributed VC systems I've come to a temporary conclusion that the set
of problems [D]VC systems are trying to solve has certain irreducible
complexity, and hence these systems either throw it onto the heads of
the users (Git) or sweep it under the rug (Mercurial, Fossil).

So it would be really interesting to see some *constructive* discussion
of different approaches such systems should take when making their
users tackle that set of problems.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why Hash

[Konstantin Khomoutov]

On Thu, 10 Sep 2015 11:29:15 -0400
Ron W  wrote:

[...]
> Personally, I would find some kind of relative specification more
> useful. For example, if I could say "fossil gdiff --from cur-3" and
> get a diff between the current check out and the revision 3 commits
> before the revision the check out is from - along the same branch.

That's what Git does (see ^N and ~N revision suffixes) [1].
Actually, its revision modifiers can do way more than that.

Mercurial's revsets [2] are also quite powerful.

1. https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
2. http://hg.intevation.org/mercurial/crew/file/tip/mercurial/help/revsets.txt
___
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 NetBSD

[Konstantin Khomoutov]

On Mon, 29 Jun 2015 08:38:10 +0200
Gour g...@atmarama.net wrote:

 recently I moved from Linux to Free/PC-BSD, but consider to switch to
 NetBSD.
 
 I recall there was talk in the past about possible migration of NetBSD
 project to Fossil DVCS. There are some Fossil repos available like
 e.g.
 
 http://netbsd.sonnenberger.org/timeline
 
 http://ftp.netbsd.org/pub/NetBSD/misc/repositories/fossil/
 
 but I wonder what is the current status in regard?
 
 Is it still considered as an option?
 
 While chatting with some people in #netbsd I got feeling that some
 devs are concsidering that Fossil does not scale for their needs.
 
 Is it something which can be overcome or usage of Sqlite (according
 to some) is the stumbling block?

I recall this one [1] as a good summary material on the subject.
It's pretty dated though -- the Fossil's performance might have
improved since then.

You might also try asking Jörg directly about this matter.
For instance, here's one of his posts [2].

1. https://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf
2. 
http://lists.fossil-scm.org:8080/pipermail/fossil-users/2013-March/012097.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] please compile official fossil builds with https support

[Konstantin Khomoutov]

On Wed, 10 Jun 2015 16:42:41 -0400
Richard Hipp d...@sqlite.org wrote:

 On 6/10/15, Eric Rubin-Smith eas@gmail.com wrote:
 
  I believe you should be able to say:
 
  # apt-get install libssl-dev
 
 
 That seemed to work.  Thanks.  I can now do the build with
 ./configure --static --disable-lineedit.  (The --disable-lineedit
 was necessary because apparently only the GNU readline package insists
 on being dynamically linked.)
 
 The new build is now on the website.

There are alternatives.  I know of [1] and [2] at least.

IANAL, but [1] looks like it would be possible to ship its complete
source code with fossil and build it directly in, when requested.

1. https://github.com/antirez/linenoise
2. http://thrysoee.dk/editline/
___
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] Curses! (foiled again?)

[Konstantin Khomoutov]

On Tue, 22 Jul 2014 13:54:25 +0200
Gour g...@atmarama.net wrote:

  MUCH easier than curses, it would seem, and a wider range of display
  colors. Isn't as portable, but it only needs to be portable to Unix
  platforms. 
 
 I plan to possibly use it with Go (language).

FWIW, there's a popular minimal support library for full-screen
terminal applications for Go called termbox [1].  It's cross-platform
(it means POSIX and Windows) and is pure Go.

I mean, if you're about writing some full-screen terminal front-end for
Fossil in Go it might be simpler to use termbox.

1. http://godoc.org/github.com/nsf/termbox-go
___
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

[Konstantin Khomoutov]

On Tue, 23 Jul 2013 11:03:09 +0200
j. van den hoff veedeeh...@googlemail.com wrote:

[...]

  While the Lua scripting enabled me to gain a level of
  sophistication and relative rigor in the process more than what I
  could get from normal UNIX
  plumbing, if my project wasn’t in Lua in the first place, I found
  it breaking my concentration a good deal more than I would have
  liked.
 
  That's my impression of lua, though i haven't worked with it (it's
  too weird, both at the script and C API level).
 
 really? regarding the language (the scripting level) I find lua  
 exceptionally well thought out and clear. the syntax is
 intentionally very boring -- no surprises here -- and sure much
 easier to swallow than tcl, for instance, for people
 starting from scratch. regarding the C level API I don't have any  
 experience (nor an opinion)
 but it claims to be much easier than that of other scripting
 languages. the LaTeX guys at least have decided to
 move into this direction to get a real scripting facility into latex  
 http://luatex.org/ which personally
 I feel was a good decision.

[...]

But please don't also miss out a first-hand experience of someone who
implemented a well-visible program centered around Lua: [1], [2].

Personally, I find that minimality (of the runtime) is the only strong
point of Lua.  Then it quickly falls apart when you hit its idiocy with
using tables for everything which is ripe with special weird cases.

Lua's stack-based API debunked in [1] also sounds bad to me as I have
decent experience with extending Tcl in C (and embedding it in C), and
I find Tcl's C API to be brilliant as well as its concept of
reference-counted objects.  Unfortunately, I have no experience using
Lua from C so I, personally, have no real say here. But still...

1. http://julien.danjou.info/blog/2011/why-not-lua
2. http://julien.danjou.info/blog/2008/rants-about-lua
___
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

[Konstantin Khomoutov]

On Sun, 21 Jul 2013 17:01:02 -0700 (PDT)
Clark Christensen cdcmi...@yahoo.com wrote:

[...]
 Scripting language: I understand the Tcl roots, and I hope you would
 consider Javascript as a target.  JS seems more universal these days.
[...]

Please, don't.  JS is a wart right from the start -- supposedly the
only popular programming language these days for which a book titled
JavaScript: the good parts has been written, which actually devoted
to teaching the prospective developers how to *not* use the
language.  Yes, there are hordes of (usually underskilled) web
developers who know JS by necessity, but IMO this is not a *technical*
consideration.  All this current hype for JS (node.js included) is a
good display of herd behaviour in human society, something not to be
proud of.
___
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 branch

[Konstantin Khomoutov]

On 13 May 2013 23:42:46 -0600
Andy Bradford amb-fos...@bradfords.org wrote:

  That is, it's backwards: you first do some work, then decide to
  commit and  decide  this commit  should  start  its  own branch
  rather  than continuing  the current  one,  so  you create  that
  new branch  while committing.
 
 Not  exactly backwards,  but  more  of a  convenience.  If you
 suddenly discover that  your changes should  not yet go  into the
 trunk,  you can branch at the moment of the  commit. This makes
 branching extremely easy to accomplish and less of a  hassle to get
 the changes committed without breaking the rest  of the sources.
 With  other VCS you would  have to go through a few  more girations
 to get your newly  changed files committed at the *right* location.

Changing a branch under a dirty work tree is achieved with a single
command in Git and two commands in Subversion; not sure about less
mainstream VCSes.  But I digress.  If memory serves me right, initially
Fossil only supported creation of a branch when committing, and
explicit branch creation has been added afterwards, per user requests.

I would say this is not about convenience but rather about different
mindsets: some people just don't feel right when they can't start a
new line of by *first* creating a branch to work on.  People with
a different mindset are fine with first coding something and then
deciding where this should go.  There definitely was at least one
thread on this list which discussed this matter, with Richard Hipp
chiming in and explaining he has the mindert of the latter kind ;-)
Of course, the convenience argument still holds, just not when it comes
to history of implementation of these features.

And if, again, memory serves me right, explicit creation of a branch
works by creating an empty commit on that newborn branch -- specifically
for the purpose of attaching the necessary tags to it, which are to
designate the branch.  I'm inclined to think this hints at that such a
mode of operation wasn't initially envisioned.
___
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 branch

[Konstantin Khomoutov]

On Tue, May 14, 2013 at 01:55:56AM +, varro wrote:

 I've been experimenting with fossil for some private projects of mine
 and now want to use the 'branch' facility.  According to the 'help'
 text for 'branch', the syntax to create a new branch is:
 
   fossil branch new BRANCH-NAME BASIS ?OPTIONS?
 
 but it doesn't explain what BASIS is.
 
 Looking at the Jim Schimpf book, I see he gives as an example:
 
   fossil branch new VER_1.0 trunk -bgcolor 0xFFC0FF
 
 Trying this on one of my own repositories, I tried:
 
   % ls -l recepsum.fossil
   -rw-r--r--  1 william  william  129024 Apr 30 21:17 recepsum.fossil
 
   % fossil branch new UI trunk -R recepsum.fossil
   fossil: use --repository or -R to specify the repository database
 
 Excuse me if I've missed something obvious here, but I've been staring
 at this and don't see what I'm doing wrong.

You seem to confuse branching with checking out a branch (to a working
directory).

You first need to open your repository:

% mkdir recepsum; cd $_
% fossil open ../recepsum.fossil

(So now you have your working directory initialized and linked to that
repository, which you can verify by running `fossil status`.)

And now you can do branching at will using `fossil branch`.

Note though that while Fossil does allow you to create a branch before
starting to work on it, it's standard mode of operation (as envisioned
by its creator) is to use the --branch command-line option when
recording the first commit on the branch which is about to be created.
That is, it's backwards: you first do some work, then decide to commit
and decide this commit should start its own branch rather than
continuing the current one, so you create that new branch while
committing.

___
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] Question about Source forge Fossil hosting

[Konstantin Khomoutov]

On Fri, 29 Mar 2013 09:10:48 -0400
jim Schimpf jim.schi...@gmail.com wrote:

   I have used Chiselapp for hosting some Fossil project but
 just got a note that he is shutting down May first.  So I decided to
 try the source forge version (http://fossilrepos.sourceforge.net/) .

I'd like to point out this is not at all a source forge version.
This is just a regular SF project created by someone -- see for
yourself [1].  To my knowledge, SF does not provide Fossil hosting.

By the way, my opinion on the matters is that ideally someone would
convince any of big players (like SF, advogato, bitbucket, berlios,
google code etc) to provide Fossil hosting as part of their existing
architecture.  Otherwise, I reckon, Fossil hosting will remain a niche
activity and will still have zero visibility as it has today.

1. http://sf.net/projects/fossilrepos
___
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] Unable to install fossil 1.23+ on my webhost

[Konstantin Khomoutov]

On Sat, Mar 09, 2013 at 09:54:10AM +0100, Stephan Beal wrote:

  I think I found the problem. I'm getting the following error when I try to
  visit a fossil with version 1.23 and the config I mentioned earlier:
  [Sat Mar 09 03:08:46 2013] [error] [client 24.200.115.71]
  /home/reallyho/public_html/cgi-bin/fossil_20120808:
  /lib/libc.so.6: version `GLIBC_2.7' not found
  (required by /home/reallyho/public_html/cgi-bin/fossil_20120808)
 
  I read some threads in the mailing list and some seems to mention that I
  could need to compile a binary of Fossil myself or try packaging an RPM.
 That's correct - your hoster seems to be running redhat(?), which is
 notorious for using really ancient system libraries (in the name of
 stability, but at the cost of pains like this one).
[...]
 ./configure (--any-options-you-need, e.g. --openssl=none for my hoster)
 make

Another option is to install a matching RH version into a virtual
machine, install gcc and the relevant library packages there, build
the executable and scp it to the hoster's machine.

On a side note: it's interesting, if it's possible to somehow tell
gcc which is building the fossil binary against a 2.7 glibc to
pretend to only link to its 2.6 ABI (or lower) symbols.
I doubt fossil really uses someting more beyond quite basic libc
facilities (plus the basic IP network stack API).

___
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] Making the go tool support fossil

[Konstantin Khomoutov]

On Thu, 21 Feb 2013 10:28:52 +0100
Lluís Batlle i Rossell vi...@viric.name wrote:

[...]
  That's correct, but Lluis is right in suggesting that we should
  have a command like:
  
fossil ping repo-address
  
  which can piggyback on the protocols supported by cloning (ssh/http
  [s]), but:
  
  a) does no authentication checks (because we cannot know which
  permissions would be required by later commands).
  b) does no useful work - simply checks for connectivity.
  c) returns a trivial response, e.g. OK or FAIL, and uses the
  exit code to report success/failure.
 
 Well it would be better if it reported something like 'fossil info'
 for tip. :)

This might contradict point (a) above in certain setups, does it?
I mean that my own repos require authentication only for pushing but
supposedly there might be some use for locked down private repos.
I just don't know is it possible to fully lock a Fossil repo so that
any access to it must be authenticated.
___
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] Making the go tool support fossil

[Konstantin Khomoutov]

On Wed, Feb 20, 2013 at 11:22:00PM +0100, Lluís Batlle i Rossell wrote:

[...]
  stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout
  http://fossil-scm.org/index.html/json/HAI | grep -q 'timestamp:'  echo
  OK || echo NOK
  NOK
[...]
 Thank you, I didn't know this. But again, this supposes we have a shell
 interpreter. We don't have a shell interpreter there, and don't want to depend
 on one. :)
[...]

Your analysis is incorrect: what you see here is mere piping of the
standard output stream of the first process (wget) to the standard input
of the second process (grep) and then running this or that code based on
the exit code of the last process in the pipeline (grep).

Two points to note here:
* Those `|'-s and -s and ||-s are, in fact, bits of the Unix shell
  syntax, but the syntax is just that -- the way a shell allows you
  to construct pipelines and check exit codes of processes it runs.
  There's no problem to construct and supervise such a pipeline in Go,
  it will just be way more verbose since Go is way more lower-level
  than a Unix shell.
  The basic approach is outlined, for instance, here [1].
* The `wget` program in that example performs a simple HTTP GET request
  and is told to output the returned content to its standard output.
  The `grep` program tries to find a specific string in the text
  supplied to it from `wget`.
  But there's no need to run anything like this in Go: its standard
  library already has the net/http package to do HTTP requests
  and the JSON parser to parse the payload a request would return.

IOW, that shell pipeline was just an example demonstrated to you, so
don't be too attached to the fact it requires a shell.
In fact, requiring `wget` is a way more serious restriction (and `grep`,
too, by the way).

If you fear that coding a HTTP request like I outlined above would mean
requirement to deviate from some common approach currently implemented in
the `go get` code, then just first rework the current code to be more
modular, and then implement your Fossil backend in it.  For instance,
implement a type of some VCS fetch function then make each backend
code (for each VCS) implement and provide such a function; then most
backends would use a simple call to exec.Command(), and Fossil backend
would be more involved.  Make sure to first bring this idea to the
golang-nuts mailing lists, and not just lurk implementing your patch
bomb secretly to just dump it on the developers later ;-) -- their
coding guidelines clearly hint at that rather involved changes should
be openly discussed first.

1. http://stackoverflow.com/a/9323144/720999

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

Re: [fossil-users] Fossil 1.25

[Konstantin Khomoutov]

On Fri, Jan 18, 2013 at 08:27:17PM +0100, Jan Danielsson wrote:

  1. Visual Studio is not in my PATH, but the following cmd seems to
  have tried and failed?
 
Don't start a normal cmd.exe; start the Start Visual Studio Command
 Line (don't remember the exact title, but you'll find it easily if you
 look for it), which should be somewhere in your Start-menu (under the
 Visual Studio folder).
 
It'll set up the environment, and you'll be able to build fossil.

Alternatively, it's possible to run the batch file which sets up the
environment.  It's usually located under the bin directory which is
under the MSVS directory.  That Start blah blah... start menu link
actually calls something like cmd.exe /k path/to/that/batch/file

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

Re: [fossil-users] Fossil 1.25

[Konstantin Khomoutov]

On Sat, Jan 19, 2013 at 12:47:59AM +0400, Konstantin Khomoutov wrote:

   1. Visual Studio is not in my PATH, but the following cmd seems to
   have tried and failed?
  
 Don't start a normal cmd.exe; start the Start Visual Studio Command
  Line (don't remember the exact title, but you'll find it easily if you
  look for it), which should be somewhere in your Start-menu (under the
  Visual Studio folder).
  
 It'll set up the environment, and you'll be able to build fossil.
 
 Alternatively, it's possible to run the batch file which sets up the
 environment.  It's usually located under the bin directory which is
 under the MSVS directory.  That Start blah blah... start menu link
 actually calls something like cmd.exe /k path/to/that/batch/file

Forgot to mention is that it's usually named like vc6setup.bat,
vc8setup.bat etc...

___
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] Right way to try something new and save/revert?

[Konstantin Khomoutov]

On Fri, 11 Jan 2013 13:06:17 +0100
Gilles gilles.gana...@free.fr wrote:

 Am I correct in understanding that this is the right way to proceed
 to try some new code, and either save it (whether it works or not,
 just as a track-record) or discard it?

 So the right way to experiment and keep tried code for later reference
 is to save those trials in a branch, distinct from the trunk.

 But since I've never used branching, I'm not clear about how to see
 which files have been saved in the branch vs. those in the trunk,

You don't need this: a branch diverges from the trunk (in your case),
rather than appearing out of the void, so initially it has the same
files in the same state the trunk does.  Moreover, the Fossil's
philosophy is that a new branch is only created when the first commit
on it is made, so you start with the trunk, do some changes then do

fossil commit --branch crazy_idea

and only then your new branch comes into existence.

Getting the diff between the starting point of the branch (or an
earlier state) is quite rarely needed -- most of the time you're
interested in the diff between your work directory (local changes) and
its base version (the last recorded commit on the current branch).
If you still need the diff between two arbitrary commits, use

fossil diff --from A --to B

where A and B are either branch/tag names or (possibly abbreviated)
hashes of the relevan commits, extracted from the timeline view.

You can omit either --from or --to, so, to diff your current checkout
to the trunk, just use

fossil diff --from trunk

 and how to check the changes made in a branch to such and such file,

Fire up Fossil web UI and click on the links marked patch and diff
in the commit view.

 and how to go back and forth between the trunk and the branch before
 applying commit.

Technically, just by doing `fossil update branchname` as this tries
to merge your uncommitted local changes with the branchname you're
switching your open checkout to.

But, again, what you're asking for is not needed as this is not how
VCSes work, so don't do that.  Instead, implement your feature on your
branch, and if you're OK with it and want it in your mainline (the
trunk), go back to the trunk and then *merge* your feature branch into
it -- this will bring all the changes implemented on that feature
branch and will record that your new commit has two parents (the trunk
and the feature branch) so you have understanable history record.
___
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] Right way to try something new and save/revert?

[Konstantin Khomoutov]

On Fri, 11 Jan 2013 17:11:44 +0100
Gilles gilles.gana...@free.fr wrote:

 Fire up Fossil web UI and click on the links marked patch and
 diff in the commit view.
 
 This is really what I want to do: Being able to see all the things I
 tried on a file in the branch. Most of the time, I want to keep track
 of things I tried just in case instead of just forgetting about them
 with fossil revert.

`fossil revert` is there for special whoops! cases, not for
organising some sort of serious workflow around it.

 Can this be done with calling a Windows application, either a regular
 editor or a differ instead of the Fossil web server? I prefer working
 with dedicated applications.

There's no official GUI front-end for fossil, but there are several
attempts at creating such a thing. Google mail archives for it,
using something like

http://www.google.com/search?q=GUI+site%3Amail-archive.com%2Ffossil-users%40lists.fossil-scm.org

to get the relevant discussions/links.  Using GUI diffing programs was
also discussed several times.

 Technically, just by doing `fossil update branchname` as this tries
 to merge your uncommitted local changes with the branchname you're
 switching your open checkout to.
 
 I was under the impression that update simply told Fossil than any
 subsequent commit should be done on that thread/trunk. Good to know
 that update will perform a merge, so it has consequences.

The logic behind `fossil update` is like follows.

Your work tree (working directory, current checkout and whatever else
it's being named) is always based on some state stored in the
repository (except for the special case when the repository has no
commits at all yet).  So the main task of `fossil update` is to bring
your work tree to the state held by the commit you supplied to this
command (directly, or via the name of a branch or a tag).  Of course,
when fossil does this, it has to be non-destructive: it should not
stomp over untracked files (files present in the work tree but not
being managed by fossil) and it should preserve your local
modifications, if any, which it does by merging.

After than, when you modify something and record a commit, that
new commit inherits certain properties from the base commit of your
work tree, and if that commit is on a branch, then your new commit
will be on that same branch, too.
___
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] Right way to try something new and save/revert?

[Konstantin Khomoutov]

On Fri, 11 Jan 2013 17:25:24 +0100
Gilles gilles.gana...@free.fr wrote:

[...]
 What I'm driving at:
 1. Keep tried but NOK algos in a branch called eg. experimental
 2. Find a simple way to locate old algo's I know I tried before by
 searching Fossil, regardless of which branch they are (trunk or
 experimental).
 
 I know Fossil doesn't support grep yet, but I find it useful to  being
 able to just commit code and know for sure that I can find anything in
 the repo.

You could go for documenting your experiments then.

First of all, you can assign arbitrary tags to the tip commits of your
experimental lines of history.  A tag view is there to select the one
you need.

Another easy possibilty is the wiki: you can refer to any commit using
its SHA-1 name in square brackets, so you can create a page titled,
say, experiments and roll something like this:

h2My experiments/h2

* [44c9e93a9187a07340da8b2984b2118990637d5a|A crazy idea]
* [8a428d5c2a0097418170509ab03faed0a335f796|Using bars to style foos]
...

where you get those SHA-1 commit names from the commit views.
The end result is that you have a nice-looking list of your
experimental lines of history, decorated by arbitrary comments.
___
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] Right way to try something new and save/revert?

[Konstantin Khomoutov]

On Wed, 09 Jan 2013 12:10:35 +0100
Gilles gilles.gana...@free.fr wrote:

 Am I correct in understanding that this is the right way to proceed to
 try some new code, and either save it (whether it works or not, just
 as a track-record) or discard it?
 
 To try some new code:
 1. Commit current code
 2. Try new code
 3.
 a. if OK, commit new code : fossil commit -m New stuff
 b. if NOK and don't care to save it, just go back to previous code:
 fossil revert myfile.c
 c. if NOK but want to keep track of attempt, commit and go back to n-1
 :
 fossil commit -m Failed attempt
 fossil finfo myfile.c : write down UUID (first hash) of n-1 revision
 fossil revert -r UUID myfile.c

AFAIK, the paradigm to handle messed up commits in Fossil is to move
them to a special branch, say, named mistake.  You do this from the
web interface.  So basically you can do a series of commits and then
decide that idea was a dead-end.  So you can go to the first commit of
that dead-end leaf and change its branch to, say, dead-end.
You then can `fossil up` to the commit preceding the first commit in
the dead-end leaf and start hacking away a new line of history.
___
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] [VB.Net] Ignoring .suo safe?

[Konstantin Khomoutov]

On Mon, Jan 07, 2013 at 11:49:52AM +0100, Gilles wrote:

 I just ran the following two commands:
 
 fossil add ./MyVBNetProject
 fossil commit -m Original files
 
 ... and fossil complains with:
 
 ./MyVBNetProject/WindowsApplication1/WindowsApplication1.suo contains
 binary data.  commit anyhow (a=all/y/N)?
 
 My global ignore-glob contains: *.exe,*.pdb,*.vb~*,*/bin/*,*/obj/*
 
 I assume there are VB.Net developers using Fossil: Do you know if it's
 safe to ignore the .suo file?
 Generally speaking, is my ignore-glob OK for VB.Net?

Yes, it's safe.
Basically, the only set of files really needed for maintaining a .NET
project by the Microsoft IDE are those containing XML in them.
The `msbuild` tool which does actual heavy lifting consumes files ending
in '*.proj' (or '*.csproj' or '*.vbproj' or whatever), plus there is a
top-level XML file which represents the solution and its settings, and
references those project files consumed by msbuild.

___
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] [VB.Net] Ignoring .suo safe?

[Konstantin Khomoutov]

On Mon, Jan 07, 2013 at 12:32:43PM +0100, Gilles wrote:

 Yes, it's safe.
 Basically, the only set of files really needed for maintaining a .NET
 project by the Microsoft IDE are those containing XML in them.
 The `msbuild` tool which does actual heavy lifting consumes files ending
 in '*.proj' (or '*.csproj' or '*.vbproj' or whatever), plus there is a
 top-level XML file which represents the solution and its settings, and
 references those project files consumed by msbuild.
 
 Thanks for the feedback. So I'll commit the following files from VB
 Express and ignore the rest:
 
 *.sln
 *.resx
 *.user
 *.vb
 *.vbproj
 *.settings
 *.myapp

Seems to be OK, but note that those .user and .settings file are not
really a part of the solution's core (I'm not sure I ever saw a .myapp
file so have nothing to say on this).  What I mean, is that it might be
useful to keep these files in the repository, but if you will eventually
decide to ship a tarball of your source code (if it's a F/OSS project),
then you will probably want to strip those files out.
Note that there were tools to do exactly this.  Can't recall any name at
the moment, but I'm sure it's googleable.

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

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

[Konstantin Khomoutov]

On Sat, 29 Dec 2012 16:20:32 +0100
Lluís Batlle i Rossell vi...@viric.name wrote:

Top post due to... okay.
The last three messages to this thread look somewhat alarming.

In the first message of these, Mike Meyer, first ruled out the whole
tool (Git) due to hating its optional feature and then proceeded with a
fancastic technical argument against it: None. Zero. Nada. Never..

The second one, from Eric, contained the exclamation Rebase is a lie!
repeated three times in a row.

And now I'm reading about Git users ashamed for the histories they
create.

sarcasmYou guys do really sound as a religious sect./sarcasm

Of course, this is a pro-Fossil list, but I fail to understand why such
bashing of a rival DVCS and preaching are really required: those who
might be converted are unlikely to read this list anyway (they're
supposedly busy reading Pro Git now), and those who are reading this
list admittedly prefer dry technical arguments.

Actually, I intended to write a calm and purely technical response to
Mike's message pointing out the ideas Git devs had while implementing
rebasing (I failed to see in this thread any notice of using rebasing to
help future bisecting, for instance), but the next two messages urged
me to write this rather off-topic semi-rant.

TL;DR
I would really like to have such discussions be more technical and less
zealous, if possible, please.

 (top post, due to the complexity of the previous post)
[...]
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Konstantin Khomoutov]

On Sat, 29 Dec 2012 10:24:05 -0600
Mike Meyer m...@mired.org wrote:

  In the first message of these, Mike Meyer, first ruled out the whole
  tool (Git) due to hating its optional feature
 
 If you're going quote someone out of context, at least get their
 reasons right.
 
 You called rebase a killer feature of git.

No, that wasn't me.

 Ok, you like it. I
 consider rebase a serious misfeature, as it reflects an underlying
 philosophy for the tool that I flat disagree with. As far as I can
 tell, rebase is *not* optional. At least, it's enabled in my install
 of git, and I've never run into a way to disable it (or, for that
 matter, a git tutorial that didn't gush about how cool and wonderful
 the rebase command was). This should be compared to mercurial, where
 rebase is available - but in an extension that's turned off by
 default. *That's* an optional feature.

No, an optional feature is the one you are not forced to use.
I have a bunch of Git users in the company I work at who never touched
`git rebase` though they supposedly read about it.  They just don't
need this feature and so they don't use it.

If you call rebasing a non-optional feature, go ahead and claim all
users of Git must commit to Subversion because Git includes the
`git svn` tool and must send patches by e-mail as it also has
`git format-patch`.

If Git had rebasing instead of merging, you could make your point, but
with the current state of affairs you can't.

 You may enjoy trying to force your philosophy onto a tool

Not me, again.

[...]
 But please don't continue wasting everyone's time by just complaining
 that people disagree with you.

I suggest you to calm down.  I see my plead to not being zealous was in
vain, so just please calm down at least.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Building Windows binary with SSL support

[Konstantin Khomoutov]

On Wed, Dec 05, 2012 at 09:18:53PM -0500, Maxim Khitrov wrote:

 I just started playing with fossil, but the lack of client SSL/TLS
 support in the official binaries is a pretty major bump in the road
 for production use. I've read all the topics that I could find on this
 subject, and I understand the arguments, but this really gets in the
 way of the simply download a precompiled binary idea. Please
 consider building a separate set of binaries and letting the users
 select which version they want to use.

The real way to get real support for TLS on Windows is to use native
implementation (schannel).  Beyond enabling xcopy deployments without
also carrying the OpenSSL runtime of a matching version along with the
binary, it would also enable using the system's certificate storage.

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

[fossil-users] Trunk not buildable with MSVC 6.0 (was: Fossil version 1.25 scheduled.)

[Konstantin Khomoutov]

On Fri, 30 Nov 2012 16:16:01 -0500
Richard Hipp d...@sqlite.org wrote:

 I have put up a change log for Fossil version 1.25 with a tentative
 release date of 2012-12-19
 
 http://www.fossil-scm.org/fossil/doc/trunk/www/changes.wiki
 
 There has been a *lot* of change since 1.24.  Please test the trunk
 version of Fossil as you are able to.  Report any issues to this
 mailing list, or file a ticket.  We want 1.25 to be a good release,
 but we need your help in testing in order to accomplish that.

Not buildable by MSVC 6.0 compiler as it started do depend on certain
wide-character string functions from newer versions of MSVC runtime.

After I've added two trivial workarounds to win\include\dirent.h
and src\cgi.c to make them compile, I've finally arrived at these
complaints from the linker:

LINK : warning LNK4049: locally defined symbol _malloc imported
LINK : warning LNK4049: locally defined symbol _free imported
rebuild.obj : error LNK2001: unresolved external symbol _wcsnlen
vfile.obj : error LNK2001: unresolved external symbol _wcsnlen
rebuild.obj : error LNK2001: unresolved external symbol _wcsncpy_s
vfile.obj : error LNK2001: unresolved external symbol _wcsncpy_s

The first two warnings are of unknown importance, but the error
messages that follow indicate two unresolved externals: wcsnlen and
wcsncpy_s.

I'm not sure if this worth fixing or not.
It seems that official Win32 builds are done using MinGW, and while it
links against the same old msvcrt.dll as MSVC 6.0 does it suppsedly
provides its own implementations of those missing functions and hence
official Win32 builds will supposedly remain as much portable as before
the new dependencies have been introduced.

I've attached the patch which fixes dirent.h and cgi.c in case someone
will find it useful.
Index: src/cgi.c
==
--- src/cgi.c
+++ src/cgi.c
@@ -21,10 +21,11 @@
 ** formatting function and its cousins, and routines to encode and
 ** decode strings in HTML or HTTP.
 */
 #include config.h
 #ifdef _WIN32
+# include winsock2.h
 # include ws2tcpip.h
 #else
 # include sys/socket.h
 # include netinet/in.h
 # include arpa/inet.h

Index: win/include/dirent.h
==
--- win/include/dirent.h
+++ win/include/dirent.h
@@ -105,10 +105,18 @@
 #include errno.h
 
 /* Windows 8 wide-character string functions */
 #if (_WIN32_WINNT = 0x0602)
 #   include stringapiset.h
+#endif
+
+/*
+ * errno_t is Microsoft-ism, MSVC 6.0 does not define it,
+ * MSVC 8.0 defines it as int, and that's what the standard says.
+ */
+#ifndef errno_t
+typedef int errno_t;
 #endif
 
 /* Entries missing from MSVC 6.0 */
 #if !defined(FILE_ATTRIBUTE_DEVICE)
 # define FILE_ATTRIBUTE_DEVICE 0x40

___
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] Is there a setting to make fossil handle UTF-8 correctly in file names and folder names?

[Konstantin Khomoutov]

On Wed, Nov 28, 2012 at 02:56:09PM -0500, Richard Hipp wrote:

  Is this a configuration issue? Or can fossil not handle special
  characters in file and folder names?
 
 Fossil is suppose to handle non-ASCII characters in filenames correctly.
 If it does not, that is a bug.  What version of Fossil are you running?
 Can you send in a detailed bug report with steps to reproduce the issue?

I'm just handwaving, but Git's code base recently received some
modifications to specifically deal with issues a native Mac OS X
filesystem have with regard to UTF-8.  AFAIK the deal was about that
filesystem pefrorming one of standard UTF-8 normalizations either when
writing or when reading (or both) so that when you create a directory
entry and then read it back, you might get an octet string different
from that you wrote.

See the extensive commit message in [1] and [2] in general.

1. https://github.com/git/git/commit/76759c7dff53e8c84e975b88cb8245587c14c7ba
2. http://en.wikipedia.org/wiki/HFS_Plus

___
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] comparison with Git

[Konstantin Khomoutov]

On Thu, Sep 13, 2012 at 04:28:00PM -0700, Russ Paielli wrote:

 OK, so apparently I misunderstood in thinking that the serverless,
 zero-administration claim applies to Fossil. Thanks for the clarification.
 
 If it were true, and if it distinguished Fossil from Git, I would have used
 it in my advocacy of Fossil.
I'd say that this aspect (tentative zero-administration) would only
be of interest to persons who routinely perform the said administration
(possibly at their $dayjob), and users (in the sense not system
administrators) are usually sold on other aspects of software.

 I am sold on the idea that Fossil is superior to Git on the basis of
 simplicity alone. Than again, I am currently a minimal Fossil user. Being
 an aero engineer rather than a developer per se, I'd rather not spend time
 learning Git. The problem, as I have said before here, is that Git seems to
 be the de facto standard for open-source software. So not knowing Git
 essentially shuts you out of most open source.
But as I understand, you're not a programmer (at least not a
hard-core type who just seek fun in learning the next big thing and
all that), so not learning Git to ride *this* wave looks to be perfectly
okay for you.

On the other hand, Git is not *that* hard to learn basic concepts,
really.  And it has external tools providing fancy GUIs, if needed.

 In addition, I feed slightly
 uncomfortable forcing someone who already knows Git to learn Fossil in
 order to work on my project. But maybe I shouldn't worry about that.
I think it highly depends on the person(s) you're considering as a
possible collaborator(s) for your project.  I'd say that learning Fossil
is not hard for anyone having decent knowledge of another DVCS system.
Another possible argument which might be used to convince someone is
that it's good to leave one's comfort zone from time to time; this
applies not only to social interactions but to programming languages and
software tools as well (and, I suppose, to many other fields I'm just
not familiar with).

You could also assess if your project would benefit from using
wiki/built-in documentation editor and issue tracker; if so, Fossil
might have a huge head start compared to other tools for you, and this
could be used when advocating its usage.

___
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] comparison with Git

[Konstantin Khomoutov]

On Thu, 13 Sep 2012 00:13:43 -0700
Russ Paielli russ.paie...@gmail.com wrote:

 I recall reading somewhere (can't seem to find it at the moment) that
 fossil is a serverless, zero-administration program. Is that true
 of git also? Thanks.

Depends on how you define serverless.
Any distributed SCM (Fossil and Git included) is specifically designed
to keep all the repository history on a local machine, so if by
serverless you mean that an SCM do not need to contact a server to
record a commit (or fetch history log or whatever else) then yes, both
Fossil and Git are serverless, and so does every other DVCS out there.

As to zero-administration, this sounds more like a flame bite rather
than a technical consideration: any DVCS system requires certain amount
of administration around it.  This might possibly refer to the fact
Fossil is self-hosting -- you can transfer its binary to a machine, run
it and it will serve the specified repository (or a set of them) all by
itself as it includes a built-in web-server which is used for both web
UI and data pushes/pulls.

The real aspect in which Fossil shines, is that it provides a turn-key
*integrated* solution consisting of an SCM (obviously), wiki, bug
tracker, project documentation editing, and user database with access
controls, all accessible/configurable via web UI, and all that is
provided by a single 1.2M binary which only depends on libc, zlib and
openssl (optionally).  This really rocks for certain applications.

You could read this classical post by Zed Shaw [1] explaining it all.

1. http://sheddingbikes.com/posts/1276624594.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new files or modified files don't get updated on the remote server file system

[Konstantin Khomoutov]

On Thu, 13 Sep 2012 14:20:12 +0100
Tommaso D'Argenio ping...@gmail.com wrote:

[...]
 Now think at this as a web development team, so we have a web
 application which doesn't need to be build or anything like that. The
 dev team create a new patch on their local repository and commit it
 to the remote testing branch. When they open up the browser to test
 it out, they won't be able to do it because the actual file in the
 remote repository it's the old one. The dev guy doesn't have the
 permission to log on the remote machine and manually run a fossil
 update, neither I can think of a process on the remote machine that
 run the fossil update command every second.
 
 For instance, I have a repository with SVN on the remote machine. I
 make some changes on my local repository (after the update done
 locally to incorporate changes made by other), and using TortoiseSVN
 I commit the changes and solve eventual conflicts with a merge. When
 this is done, I open up the web app on the browser and there it is my
 change.
 
 Am I making any sense ?

Not much: a Subversion repository on a server does not have an open
checkout attached to it at all.  So could you please describe in more
details what you're trying to achieve?

So far it seems you want to somehow automagically update certain open
checkout of a Fossil repository after you push new changes to a
specific branch in that repository.  Is this true?

Then how precisely this is implemented in your Subversion setup?
I, for one, cannot really imagine this.

Note that a Fossil repository can have any number of open checkouts
active at the same time, all of them independent from each other.
This should hint you at that Fossil kind of work backwards here: open
checkouts refer to the repository, not the other way round.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new files or modified files don't get updated on the remote server file system

[Konstantin Khomoutov]

On Thu, 13 Sep 2012 16:04:58 +0100
Tommaso D'Argenio ping...@gmail.com wrote:

  By the way I've also checked the autosync setting and it is set to
  ON, on both machines. Reading from the documentation
[...]
 just to add to this. I've set the remote-url with the correct server
 url and a user with developer permissions (at later stage I've also
 added admin and setup permissions, thinking that developer wasn't
 enough but no changes), and when I do commit I can see that fossil is
 sending data to the remote server via the autosync function I guess.
[...]
 What I'm doing is what it's written in the documentation as autosync
 workflow, yet it doesn't work. I'll probably just give up :(

I fail to see a problem statement here.
Autosync means that each time your commit, Fossil contacts the remote
repo and sees if the branch you're about to commit has been updated by
someone other's commit(s), and if it is, the contents is fetched and
you're requested to first do local merge and then re-try the push.
Otherwise, a fork would occur (a branch with two leaves).
You demonstrated that autosync works, so what's the problem?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] new files or modified files don't get updated on the remote server file system

[Konstantin Khomoutov]

On Thu, 13 Sep 2012 14:57:03 +0100
Tommaso D'Argenio ping...@gmail.com wrote:

 I don't maintain the SVN server so I can't comment on the way it's
 configured.

That's probably important -- see below.

 My workflow is quite simple:
[...]
 -Right click on the folder  Tortoise  Commit and enter comment
 -Resolve conflicts (eventually)
 -Done, new files and update files on the server

Okay, this most probably means your repository has a so-called commit
hook which performs deployment of the checked in changes after each
commit is recorded.  A hook is usually a shell script (but it might be
any program at all) which is run by the SCM server software after a
specific event happens (a commit in this case).

AFAIK stock Fossil does not support hooks, but they can be possibly
implemented in a special build, see [1].

A much simpler way, as Richard have already proposed, might be to
deploy a no-brainer CGI script which would perform the deployment.

In the simplest form that could be a form with a button; in a more
elaborate case -- an entry for the revision (defaulting to the name of
some branch) to check out and the button.  The only problem I observe
with this setup is possible permissions issue: the credentials used by
your web server should provide read access to the relevant
repository file (may be even write access for SQLite locking to work --
I don't know this stuff to this level of detail, sorry).

1. 
http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008221.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] trouble handling text files from SQL Server 2012

[Konstantin Khomoutov]

On Thu, Sep 13, 2012 at 03:43:16PM -0400, Kevin Greiner wrote:

 I'm using fossil 1.23 on Windows 7. I'm attempting to store text files
 generated by Microsoft SQL Server 2012 in fossil so I can easily track
 their changes over time.
 
 The problem is that fossil thinks these generated text files are binary
 data which prevents me from viewing the files via the web ui and generating
 diffs.
 
 When I look at these files in a hex edtor, I see this: ff fe 53 00 45 00 54
 00 20 00 41 00. A text editor shows SET A.
This is a BOM (Byte-Order Mark) [1] followed by five UTF-16-encoded
characters comprising the string SET A.

 I've looked in the email list archive where DRH specifies that a null
 character or a line longer than 8192 chars. The entire file is 1074 bytes
 so it's not the length. Is fossil reading the 00 bytes as nulls?
 
 Any idea why fossil thinks these files are binary? And, more importantly,
 what encoding I can specify to prevent this? I've tried various
 permutations of ASCII, UTF8, UTF7 to no effect.
UTF-8 should be fine.  I dunno why fossil would consider an
UTF-8-encoded file as binary for byte sequences representing non-NUL
characters (including BOM) in UTF-8 do not contain zero bytes.

1. http://en.wikipedia.org/wiki/Byte_order_mark

___
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] Something like rollback

[Konstantin Khomoutov]

On Wed, 15 Aug 2012 22:13:38 -0400
Simon Tremblay stm...@hotmail.com wrote:

 On 8/15/12 12:21 PM, Nick Zalutskiy wrote:
 Ideally I'd like to revert that commit somehow and do two smaller 
 commits thereafter. Since there is no rewriting history in fossil, I 
 assume that this would involve doing a new commit that is the 
 opposite of the incorrect one, and then replying the changes one a
 time. How would I do this?
 
 I'm not familiar enough with fossil to recommend you the best
 solution for your problem.
 
 But, an uncommit feature is currently in the fossil to do list at:
 http://www.fossil-scm.org/index.html/wiki?name=To+Do+List
 
 It has been added on 2012-08-07.

I have recently asked about something like `git revert` and have been
given an answer [1] that the way to back out a selected commit is to do
$ fossil merge --backout that_commit_sha1

I'm not sure you can easily do that replying changes one at a time
after that.  You could, in theory, get the diff introduced by the
reverted commit, save it to a file and then apply it hunk-by-hunk
exercising your text editing skills and the `patch` program.

1. http://permalink.gmane.org/gmane.comp.version-control.fossil-scm.user/9691
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Error building Fossil v1.23 against SQLite v3.7.3

[Konstantin Khomoutov]

I'm trying to build Fossil v1.23 for Debian Lenny using

$ ./configure --prefix=/usr/local/bin --disable-internal-sqlite

and I'm getting these linkage errors:

/usr/local/src/fossil/./src/db.c:1032: undefined reference to
`sqlite3_db_readonly' bld/report.o: In function `sqlite3_exec_readonly':
/usr/local/src/fossil/./src/report.c:864: undefined reference to
`sqlite3_stmt_readonly' bld/report.o: In function
`verify_sql_statement': /usr/local/src/fossil/./src/report.c:261:
undefined reference to
`sqlite3_stmt_readonly' /usr/local/src/fossil/./src/report.c:261:
undefined reference to `sqlite3_stmt_readonly' collect2: ld returned 1
exit status make: *** [fossil] Error 1

SQLite version installed is 3.7.3 (the development package matches it):

$ apt-cache policy libsqlite3-0|grep -i installed
  Installed: 3.7.3-1~bpo50+1

Does this mean Fossil uses certain SQLite API functions which appeared
after the 3.7.3 release?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Konstantin Khomoutov]

On Fri, 3 Aug 2012 12:19:01 +0200
Michal Suchanek hramr...@gmail.com wrote:

  Why markdown and not one of the dozens of other wiki syntaxes?
 
  Because markdown is a very popular one, used by github, and we have
  on board the creator of a major implementation (the one used by
  github, iirc).
 
 The others are also very popular.
 
 Github has a cute logo but I would not turn to it when looking for
 sound technical solutions.
Stackoverflow and all the sites under its umbrella, and all the sites
using this engine, use (modified) markdown syntax [1], [2].

I, for one, while not being a special fan of markdown syntax (to me, the
best sytnax I ever had to deal with was that used by wiki.tcl.tk), still
think that the proliferation of wiki markups place everyone in position
where one just can pick a syntax to use almost at random.
Markdown is a) popular; b) has a (seemingly) sound C library
implementation.  Hence to me it looks like a perfect choice for a
project like Fossil.

[...]

1. http://blog.stackoverflow.com/2009/10/markdown-one-year-later/
2. http://stackoverflow.com/editing-help/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Konstantin Khomoutov]

On Fri, 3 Aug 2012 15:06:45 +0200
Michal Suchanek hramr...@gmail.com wrote:

[...]
 Stackoverflow and all the sites under its umbrella, and all the
 sites using this engine, use (modified) markdown syntax [1], [2].
 So again a somewhat slightly incompatible variation.
Correct, but I hardly perceive this as being an issue.

[...]
  I, for one, while not being a special fan of markdown syntax (to
  me, the best sytnax I ever had to deal with was that used by
  wiki.tcl.tk), still think that the proliferation of wiki markups
  place everyone in position where one just can pick a syntax to use
  almost at random.
 And for fossil it has been picked already.
The idea behind pushing Markdown (or whatever else) engine to Fossil
is providing a *rich* set of markup capabilities.  The problem with
builtin Fossil markup engine is that its too simplistic to be usable.
In fact, it's usable for one-line pages, but as soon as you want to
roll something a bit more complicated (itemized/numerated lists being
the first feature I need) you bump to the need of writing HTML, with no
support from the UI to do so.
I do understand the rationale for this approach; if I were the author
of Fossil (I'm incapable for this, but let's pretend I am, for the
moment) I'd probably pick the same approach during an early phase of
development.  Now it seems that quite many users see overly simple
markup capabilities of the Fossil's wiki engine to be a problem; a
soultion exists and is even integrated.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Konstantin Khomoutov]

On Fri, 3 Aug 2012 14:02:38 +0200
Natacha Porté nata...@instinctive.eu wrote:

[...]
 As I have said elsewhere, I'm not clever enough to imagine a solution
 to introduce markdown into fossil's internal wiki. So I don't propose
 it. I propose the extra embedded doc rendering, and the tools to
 perform any markdown-to-html conversion. When someone comes up with a
 way to deal with the internal wiki, they will have such tools.
Ikiwiki allows to use several different markup engines for its pages
(markdown is builtin, others can be installed in the form of plugins),
and it allows the author to pick the markup engine for the page at the
time the page is created (see the attached image).

The type of markup syntax selected for the page is then codified in the
extension of the file which is created by the wiki engine for that page.

Supposedly, Fossil's wiki page editor could provide the same pick list
the first time a page is created and then persist the chosen markup
syntax with the page entry itself in an appropriate table.

Is that possible?

[...]
attachment: ikiwiki-page-editor-syntax-pick-dropdown-list.png___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Konstantin Khomoutov]

On Fri, 3 Aug 2012 15:42:05 +0200
Stephan Beal sgb...@googlemail.com wrote:

  I do understand the rationale for this approach; if I were the
  author of Fossil (I'm incapable for this, but let's pretend I am,
  for the moment) I'd probably pick the same approach during an early
  phase of development.  Now it seems that quite many users see
  overly simple markup capabilities of the Fossil's wiki engine to be
  a problem; a soultion exists and is even integrated.
 Another consideration here is that the wiki has kind of fallen out of
 use, with the embedded docs system generally being preferred. While i
 admit that i pay a good deal of attention to fossil's wiki API (i've
 added several of the wiki subcommands and the wiki API was amongst
 the first of the JSON APIs added), i will admit that embedded docs
 are generally a better solution. But the wiki is just too convenient
 (which is the only reason anyone really uses a wiki, anyway). Once i
 get embedded docs support in the JSON API, i probably won't touch the
 wiki API again.
My personal use case for Fossil's intergated wiki is a structured place
to perform brain dumps: that is, I have a problem to solve (and I'm
writing code which is to solve it, hosting it using Fossil), and start
to write down my observations on how to attack different parts of it,
findings on the nature of the data I had to process etc.  This fits the
wiki paradigm rather well and does not really fit to the domain of the
built-in documentation.  Unfortunately, in my case I did have the need
to use nested lists, convenient ways to insert multiline verbatim bits
of text, and I'd love to have some (basic) support for tables (what
ikiwiki has [1] would be just enough).

Uploading images and inserting wiki links to them would also be a win
for me (again, ikiwiki provides for this; this is called attachments
in its lingo [2]).  This would probably be an overkill for a markup
engine built into Fossil, but I found myself wanting this feature more
than once.
Yeah, every time I think about this I do understand I could just
create a page in my intranet ikiwiki instance an link to it from my
Fossil's project's wiki page, but this kind of questions the whole
point of having a built-in wiki engine. ;-)

P.S.
I'm constantly referring to ikiwiki because it stores all its content
in a [D]VCS (Git in my particular case), and so does Fossil with its
wiki engine.

1. http://ikiwiki.info/ikiwiki/directive/table/
2. http://ikiwiki.info/plugins/attachment/
___
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 enable showing timeline timestamps using local time without touching the web UI?

[Konstantin Khomoutov]

I use fossil to manage configuration files of certain programs on a
bunch of machines which I access over SSH.

I'd like to enable displaying timeline timestamps using local time
as there are no people in other time zones working with these projects
and hence seeing immediately understandable timestamps would be a win.

I know which flag to tick in the web UI to achieve what I need but the
problem is, there's no convenient way to use web UI while being inside
a screen session over SSH.

I looked at the output of `fossil settings` and inspected the result of
`fossil config dump all /tmp/fossil.conf` but can't see a way to set
this option.

Any ideas?

P.S.
To be precise, I want the output of `fossil timeline` to display
timestamps using local time.
___
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 reverse a committed changeset in Fossil?

[Konstantin Khomoutov]

Is there a way to reverse a committed changeset in Fossil?

I mean, I have a timeline ...-A-B-C and would like to reverse a
change introduced by B.  This logically amounts to generating a patch B
introduced then trying to reverse-apply it onto C (what would
`patch -R ...` do).
In Git, I would do this by `git revert B` and in Subversion by
`svn merge -c B -M PATH`.

Is there something like this in Fossil?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] How to reverse a committed changeset in Fossil?

[Konstantin Khomoutov]

On Fri, 13 Jul 2012 06:26:21 -0700
Richard Hipp d...@sqlite.org wrote:

  Is there a way to reverse a committed changeset in Fossil?
 
  I mean, I have a timeline ...-A-B-C and would like to reverse a
  change introduced by B.  This logically amounts to generating a
  patch B introduced then trying to reverse-apply it onto C (what
  would `patch -R ...` do).
  In Git, I would do this by `git revert B` and in Subversion by
  `svn merge -c B -M PATH`.
 
  Is there something like this in Fossil?
 
 
 fossil merge --backout B
 # test the merge
 fossil commit

Thanks!  The way merge --backout REV reads makes sense to me now that
I know about it.
___
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] Security of Fossil

[Konstantin Khomoutov]

On Wed, May 30, 2012 at 10:56:15PM -0500, Thomas Stover wrote:

  By my second question, I meant Fossil's Administrator account, not
  that of windows.  Assuming that I don't find a solution for people
  brute-forcing passwords for regular accounts, that's not a big deal.
  However, if people can brute-force the Fossil Admin account, then
  that would be a problem.
  
  Similarly, if there was a feature where an account would get locked
  out after 3 incorrect logins, that can't apply to the Admin account,
  or else we wouldn't be able to unlock, etc.
[...]
 ok that makes sense. I do know that you can unlock the admin account
 by just doing a fossil ui on it locally, which I have done when I
 have just forgotten the password. I'd like to see what the other
 answers turn out to be.
fossil user password username -R repository_file.fossil
works just fine for changing the password for a user.

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

[Konstantin Khomoutov]

On Mon, 2 Apr 2012 20:41:16 +0200
Sander Reiche sander.rei...@gmail.com wrote:

 Maybe I'm missing something like a magic argument to 'fossil add', but
 this is not an error I'd like to see on a source control program
 supported on a UNIX platform :)
 
 fossil: filename contains illegal characters:
 lite2/local/MACH/386/sys/standi386at/binaries/bin/[
 
 I guess it's the '[', but come on...

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

Please do some minimal google research next time.
Using a sensible phrase for the message subject is advised as well.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] can a repo be local and global?

[Konstantin Khomoutov]

On Wed, 21 Mar 2012 16:49:12 +0200
ST smn...@gmail.com wrote:

 can a repo be local and global at the same time, i.e. if I want to
 provide access to my repo through apache - do I need to have one repo
 for apache and one local or can it be one and the same repo?
It can: you do this every time you run `fossil server` in an open
checkout. `fossil ui` basically does kind of the same: it runs fossil
in server mode and spawns a local browser which is then told to connect
to the port opened by the serving fossil instance.

 If it can be one and the same repo does this mean that I don't need to
 make push/pull only commit/update?
That is correct.
Just be aware of the fact that your local checkout is not automatically
updated by foreign pushes to the same branch.
I mean, if you have, say, a branch trunk currently checked out, and
it's updated externally you'll have to update your checkout or your next
commit will create a fork.
___
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] moving repository

[Konstantin Khomoutov]

On Wed, 21 Mar 2012 09:30:55 -0400
Altu Faltu altufa...@mail.com wrote:

 Is following sequence supposed to work for moving repository?
 
 C:\testfossil new test.fsl
 C:\testfossil open test.fsl
 C:\testren test.fsl new.fsl
 C:\testfossil test-move-repository new.fsl
 C:\test\fossil.exe: repository does not exist or is in an unreadable
 directory: C:/test/test.fsl
 
 C:\testfossil test-move-repository c:\test\new.fsl
 C:\test\fossil.exe: repository does not exist or is in an unreadable
 directory: C:/test/test.fsl
 
 C:\testfossil version
 This is fossil version 1.22 [5dd5d39e7c] 2012-03-19 12:45:47 UTC
Same problem here with 1.21 also on Windows.
Not renaming the original repository before running the command
complains that the target repository does not exist.
So in the end there seems to be no way to actually run this command
successfully.
___
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] moving repository

[Konstantin Khomoutov]

On Wed, 21 Mar 2012 10:08:58 -0500
Bill Burdick bill.burd...@gmail.com wrote:

[...]
   C:\testfossil test-move-repository c:\test\new.fsl
   C:\test\fossil.exe: repository does not exist or is in an
   unreadable directory: C:/test/test.fsl
  
   C:\testfossil version
   This is fossil version 1.22 [5dd5d39e7c] 2012-03-19 12:45:47 UTC
  Same problem here with 1.21 also on Windows.
  Not renaming the original repository before running the command
  complains that the target repository does not exist.
  So in the end there seems to be no way to actually run this command
  successfully.
  What about copying the repository, doing a test-move-repository,
  and then removing the original?
 Or, you could hard link it, instead of copying it, if the new
 location is on the same volume as the old (hard linking works on
 windows, too).
Following this line of thinking I could as well just run sqlite3
command-line binary on the checkout fossil database and manually hack
the necessary entry in an appropriate table.

What the OP implied is that that command's implementation
probabaly contains a bug and I demonstrated that it indeed seems so.

Also see this discussion:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg06792.html

P.S.
Please don't top-post.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Side-by-side with checked out content

[Konstantin Khomoutov]

On Fri, 9 Mar 2012 11:37:37 +0100
Jos Groot Lipman donts...@home.nl wrote:

 Is it possible to see a side-by-side difference between the last
 checkin and the currently changed file on disk? It would be a great
 alternative to fossil diff and fossil gdiff
 
 This would be much like the wiki preview using /doc/ckout/
Sorry for nitpicking, but I maintained an impression wiki pages are
unversioned, only embedded documentation pages are and such preview of
the checked out version is rather implemented for embedded
documentation.
___
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] ASCII filename issue

[Konstantin Khomoutov]

On Tue, 6 Mar 2012 13:21:14 +0200
Ștefan Fulea fulea.ste...@gmail.com wrote:

 Fossil doesn't seem to get along with square brackets:
 Z:\fossil add file[N].x
 Z:\fossil.exe: filename contains illegal characters: file[N].x
 
 I saw that there is already an open ticket about Unicode filenames,
 but since square brackets are valid ASCII characters for filenames (at
 least both on *nix and Windows), this issue can stand separated.
It's considered to be a feature and was discussed several times before.
See [1] as an example.

1. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg06209.html
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil stash gdiff

[Konstantin Khomoutov]

On Mon, 5 Mar 2012 08:47:27 -0500
Richard Hipp d...@sqlite.org wrote:

[...]
  It seems the program is started with parameters like
  /temp/xDjd8RXRlXyBTEo /temp/RgKiAnjkXUrB61Z, and I can see some
  temporary files like this created, but obviously winmerge cannot
  pick them up.
 
  Some things I don't understand:
 
  -- why '/temp' on Windows? Obviuosly this does not use an
  environment variable. I have such a directory, but what if I hadn't?
 
 
 See http://www.fossil-scm.org/fossil/artifact/3e15b2476f1e?ln=861-903
 for the current algorithm for finding temporary filenames.  How would
 you suggest that this code be improved?
Windows code is expected to use GetTempPath() [1] and
GetTempFileName() [2] API calls.  Probably a way to go would be to use
two source files implementing file_tempname(): one having the current
implementation (for POSIX systems) and another one for Windows--which
would call GetTempFileNameW() to obtain a temporary file name and
then recode it to UTF-8 using a call to WideCharToMultiByte() [3].

I also wonder: why is custom code used on POSIX instead of mktemp()?

1. http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992.aspx
2. http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991.aspx
2. http://msdn.microsoft.com/en-us/library/windows/desktop/dd374130.aspx
___
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] Behavior of rm, mv, and changes/extra

[Konstantin Khomoutov]

On Tue, 28 Feb 2012 08:22:52 -0500
Leo Razoumov slonik...@gmail.com wrote:

  (1)  fossil rm removes the files from the disk
  (2)  fossil mv renames the files on disk
 
  (3)  fossil settings crnl-glob **
  (4)  fossil update == fossil update current
  (5)  Unlimited undo (purgin old undos after a defined number of
  days)
  (6)  Explain in more detail the clock problems with the commit.
  People do not understand. Propose solutions
 
 
   (7) push/pull individual branches
   (8) search through wiki pages, timeline, tickets (fossil-scm.org
   branch exp-search [1] can be a good start)
Anything starting with (3) is not about interface changes but rather
these are feature requests.

I have one feature request which does have something to do with
interface: I'd like to see a set of sensible shortcuts to operate on
tags for common cases, like make this commit start a branch named
`mistake' (or a leaf of it) and then close this leaf immediately.
Currently fossil has very low-level support for tags accessible from
its command line which require deep level of knowledge about how tags
are organized, what's the deal about symbolic vs raw tags, what are
propagating tags etc--this is all plumbing commands (the term borrowed
from Git lingo), and I, as a user, would like to have a set of
higher-level commands to operate branches and leaves.

Yes, I know about web interface (which is cool, no doubts) but I'm often
using fossil while being logged over SSH where using `fossil server` is
technically feasible but requires thinking about establishing SSH
portforwarding up front which is inconvenient.
___
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] Behavior of rm, mv, and changes/extra

[Konstantin Khomoutov]

On Tue, 28 Feb 2012 14:47:00 +0100
Ramon Ribó ram...@compassis.com wrote:

[...]
 (9) in the web page, possibility to mark branches as hidden. It will
 be invisible in the timeline, branches section and files section
 (files belonging only to hidden branches do not appear), unless a
 special option to show hidden is selected. (useful to hide mistakes)
Is this really needed?
After making a check-in a leaf in the mistake branch, close this leaf
immediately; this way, the mistake branch at any point in time will
contain only closed leaves and therefore it will be itself closed and
not shown among the active branches.

To me, the concept of hidden branches appears to be a misfeature.
___
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 artifact not complaining

[Konstantin Khomoutov]

On Fri, 10 Feb 2012 15:35:13 +0100
frantisek holop min...@obiit.org wrote:

   I think it should be fixed to a better behaviour (the command to
   emit an error
   and not overwrite the file).
  
  
  i've patched this locally to do:
  
   [stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe
  ./fossil: Could not resolve artifact name/ID.
 
 how about:
 
 $ ./fossil artifact abcdcafe
 ./fossil: abcdcafe: no such artifact
Sorry for another bikeshedding plug, but if we recall how perror()
works, a more Unix-way approach to error reporting whould be reverse
the static and varying parts, so that the error message becomes:

no such artifact: abcdcafe
___
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] make fossil up 'quiter'

[Konstantin Khomoutov]

On Thu, 9 Feb 2012 08:19:36 -
Eric e...@deptj.eu wrote:

[...]
  $ fossil up
  Autosync:  http://www.fossil-scm.org/
  Bytes  Cards  Artifacts Deltas
  Sent: 177  2  0  0
  Received:2608 57  0  0
  Total network traffic: 319 bytes sent, 1565 bytes received
[...]
  While I agree with you on this topic, a relatively easy way to spot
  that there probably was a check-in is to look for non-zero count in
  the Deltas column in the Received row. Non-zero Artifacts
  count means that there were *some* changes, but they could relate
  to anything (bugs filed, their state changed, wiki changes etc),
  and non-zero Deltas indicates some files managed by fossil has
  been changed.
 
  Having said that, an output akin to Git's one would be way more
  helpful in the general case: the list of branches which received
  updates with symbolic indication about the kind of update occured.
 
 fossil update is concerned only with the branch you have in your
 checkout directory. If autosync is on it does a pull first, but
 that's a separate operation, and it os concerned only with artifacts
 in the repository and knows nothing about branches.
The case presented by the original poster involved the pull step which
appears to have suboptimal approach to reporting what we got from the
remote repository.  If you have autosync turned off (as I do everywhere,
for instance) I just pull by hand, which changes nothing in
this regard.  That's why I referred to Git which, when you do
pulling (it's called fetching in Git lingo) tells you artifacts
for which branches it received, so you have an immediate idea about
what has been changed on the remote.  Hence my reference had nothing to
do with Git's *workflow* in particular.

 I wish people would stop expecting fossil to behave like git, if it
 did you might as well use git.
Please keep religious zealotry out of this list.
Or at least try not to express it unless you are 100% sure you
understood what the person to whose message you're responding to wanted
to state.
___
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] make fossil up 'quiter'

[Konstantin Khomoutov]

On Thu, Feb 09, 2012 at 01:55:01AM +0100, frantisek holop wrote:

 fossil always reports the latest artifact ID and commit message
 whenever doing 'fossil up', even though actually there was no new
 check-in.
 
 for example:
 
 $ fossil up
 Autosync:  http://www.fossil-scm.org/
 Bytes  Cards  Artifacts Deltas
 Sent: 177  2  0  0
 Received:2608 57  0  0
 Total network traffic: 319 bytes sent, 1565 bytes received
 --
 updated-to:   9b1d394a719f00f5a293612fe824e1a1fb1ed2e4 2012-02-08 03:04:23 UTC
 tags: trunk
 comment:  Update the version number to 1.22 and begin entering change log
   information for the next release. (user: drh)
 
 
 this confuses me sometimes thinking there was a new check-in :[
 wouldn't it be more natural not to print anything if the local
 check-out is exactly as the remote one?  and have this repeating
 output as part of the --verbose output?  what do you think?
While I agree with you on this topic, a relatively easy way to spot that
there probably was a check-in is to look for non-zero count in the
Deltas column in the Received row. Non-zero Artifacts count means
that there were *some* changes, but they could relate to anything (bugs
filed, their state changed, wiki changes etc), and non-zero Deltas
indicates some files managed by fossil has been changed.

Having said that, an output akin to Git's one would be way more helpful
in the general case: the list of branches which received updates with
symbolic indication about the kind of update occured.

___
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] documentation clarification

[Konstantin Khomoutov]

On Wed, 01 Feb 2012 10:18:18 -0400
Chris Peachment ch...@ononbb.com wrote:

[...]
 The wonders of the internet include the Network Time Protocol
 (http://www.ntp.org/) and I think all major operating systems
 have a mechanism for enabling it, if that is not the default.
 It is then possible to have synchronised time keeping to a
 meaningful level of precision.
 
 I can't speak for MS-Windows or MacOS but Ubuntu Linux uses
 NTP by default.
Windows (at least, since Windows XP) has native NTP client
which one just have to set up more sensibly.
For instance, [1] appears to be a quite sensible guide.

1. http://www.cumps.be/nl/blog/read/howto-set-up-ntp-on-windows-vista
___
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] Keeping password on clone

[Konstantin Khomoutov]

On Mon, 16 Jan 2012 13:28:46 +
Kevin Martin ke...@khn.org.uk wrote:

 I have looked through the documentation, and I really can't seem to
 figure this out.
 
 I set up a repository on a server.
 
 fossil init test.fossil
 fossil server -P 1
 
 I VPN on to the remote network, and from my local machine do a fossil
 clone
 
 fossil clone http://kev82@172.28.48.1:1/
 
 which then resets my password on the local repository. Although auto
 sync does work.
It does not reset your password; it rather creates a single user for
this repository, which is then granted admin privileges.

The idea is that cloning only fetches the data, that is, artifacts
which are commits, trees, blobs, wiki pages, bugs, documentation etc.
The configuration, even though it's physically kept in the same
database file, is an orthogonal concept and it's quite logically
excluded from cloning because different hosting locations of the same
data might have radically different requirement for the scenarios
of accessing it.

If you happen to have the same username on both machines, the user
names of these admin users of both your repositories will be the same
and that's what probably made you think the user list is cloned.
You can override the admin user name of a newly-created local repo using
the --admin-user|-A option when cloning.

 I know this is a minor problem because fossil ui seems to
 automatically log me in on the local repository, but I'd prefer it if
 I could keep the passwords the same. Is there a way to do this?
Change your local password by running 
$ fossil user password $username [-R /path/to/repo.fossil]
(the optional bit is only needed if you run this command not within an
open checkout).

Probably you can also pull the configuration from the remote
repo using
$ fossil config pull user
(I'm not sure it will work though--never did it myself).
___
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] Check out files directly from remote repository

[Konstantin Khomoutov]

On Tue, 10 Jan 2012 21:24:00 +0100
ma...@include-once.org wrote:

 Probably missing something very obvious. But how do you
 get the current set of files from a remote repository? (Using
 the command line, not the server UI.)
 
 With SVN or GIT you can just do a checkout on the server
 url with e.g.
 svn co http://svn.example.org/repos/proj/trunk proj
 git clone git://examplehub.com/jquery/jquery.git
 
 In Fossil this seems to require at minimum two steps:
 
 fossil clone http://fsl.example.com/repo local.fsl
 fossil tarball -R local.fsl trunk /dev/stdout | tar tz
 
 But cloning the remote repository is obviously redundant
 if you just want the current set of files. Is there a shortcut
 for this?
You seem to have some deep confusion about how Git works:
`git clone` brings in the full repository history, then it just checks
out a branch the HEAD ref in the remote repository points to, and that
appears to you to be the current set of files

In fossil, the equivalent to your `git clone` command would be
fossil clone $URL repo.fossil
mkdir repo; cd repo
fossil open ..\repo.fossil
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Translation

[Konstantin Khomoutov]

On Wed, 21 Dec 2011 17:56:46 +0100
BohwaZ boh...@bohwaz.net wrote:

 I'm wondering if there is  way to translate the Fossil web interface?
 
 Is it planned? That would be nice for us, non-english speaking users.
I disagree.

Translation to several languages would mean bloat.  That might be okay
for an already bloated project like a compiler suite (though I disagree
with their localization as well) but not for a tool which has
self-containment and low footprint as one of its top selling points.

Possibly the way to go is to create a separate (CGI?) application that
would implement a rich webserver around fossil (by hooking it via
JSON API if I understood its intent correctly).  Such a project would
also be a good point to channel the energy of the folks admiring
the rich client paradigm with flashy and shiny stuff in the UI.

Another issue with translated stuff is that often one needs to
reverse-translate some bits of the interface back to English to
actually understand what the original term stood for.

P.S.
Sure, if someone invents a way to make this stuff optional (say, fossil
would try to look up translated resources in some well-known place at
startup or such resources would have a possibility to be embedded into
the binary with this feature turned off for default and official
builds) then that would be OK, of course.
___
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 1.21

[Konstantin Khomoutov]

On Tue, 13 Dec 2011 11:56:42 -0500
Richard Hipp d...@sqlite.org wrote:

 Point of curiosity: Is there a Twitter feed for Fossil?
 
 I was thinking the other day that it might be cool to have a feature
 whereby a Fossil server would tweet every time it got a new check-in
 or ticket or wiki edit, etc.  Any volunteers to contribute code?
Why tweet?  This is a proprietary service for little girls and
housewives.  Providing an RSS feed on relevant pages (timeline, namely)
would be just right (some wiki engines do this for their changes page
for instance).
___
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] Trying out fossil: two issues with branches and empty folders

[Konstantin Khomoutov]

On Mon, 14 Nov 2011 12:32:40 +0100
Stephan Beal sgb...@googlemail.com wrote:

[...]
 Fossil doesn't track directories. If you want to get rid of empty
 ones, one way to do this in Unix is:
 
 find . -type d | xargs rmdir
 
 Notes:
 
 a) rmdir will refuse to delete non-empty dirs, so the above will
 likely spit out harmless warnings for non-emtpy dirs.
 b) spaces and whatnot in the names will break the above (how
 best/easiest to fix it depends partly on whether you're using GNU
 find or not).
With GNU find it should be possible to just do
find . -type d -empty -delete
___
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] Using althttpd.c

[Konstantin Khomoutov]

On Thu, Nov 10, 2011 at 10:57:37PM +0100, Paolo Bolzoni wrote:

 Today I tried to use althttpd.c as HTTP server for serving few fossil
 scm. But I cannot execute CGI scripts.
[...]
 Now once I start xinetd if I go to 127.0.0.1 with my browser
 the server greets me saying there is no document in / that is fine.
[...]

Is there any reason not to run fossil directly from inetd to serve a
directory with repositories?  Fossil is really self-hosting and does not
need a HTTP server because it's itself a HTTP server.

For instance, I have:

~% grep fossil /etc/inetd.conf   
8080 stream tcp nowait fossil /usr/local/bin/fossil /usr/local/bin/fossil http 
/var/local/lib/fossil/

That /var/local/lib/fossil/ directory contains a set of *.fossil files.
This allows me to use http://that_host:8080/repo/ to acces the
repo.fossil repository.  This works for both kinds of access: using
fossil client for pushes/pulls and using a browser for interactive
stuff.

___
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 list commits made so far?

[Konstantin Khomoutov]

On Mon, 07 Nov 2011 15:10:12 +0100
Gilles gilles.gana...@free.fr wrote:

[...]
 One thing I'm not clear about, is how fossil timeline works: When
 using -n 5, it shows three lines, while -n 10 shows five lines,
 and -n 20 shows eleven :-/
 
 http://fossil-scm.org/index.html/help?cmd=timeline
 
 What does timeline show, really?
I can guess that's the effect of timeline defaulting to showing tickets
and wiki edits as well as commits.
What happens if you do
fossil timeline -t ci -n 20
?
___
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 list commits made so far?

[Konstantin Khomoutov]

On Mon, 7 Nov 2011 15:45:16 +0100
Lluís Batlle i Rossell virik...@gmail.com wrote:

  I can guess that's the effect of timeline defaulting to showing
  tickets and wiki edits as well as commits.
  What happens if you do
  fossil timeline -t ci -n 20
  ?
  
  Good idea, but still strange:
  
  C:\Projects\Project1fossil timeline -n 5 -t ci
  = Shows three commits
  
  C:\Projects\Project1fossil timeline -n 10 -t ci
  = Shows five commits
 
 'n' sets the maximum number of lines, iirc.
`fossil help timeline` from v1.20 I have installed mentions N twice:
1) In the command-line spec--that ?-n N? bit;
2) In the description text, where it's clearly placed in the context
   of check-ins.
___
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] iOS and Android?

[Konstantin Khomoutov]

On Sun, Nov 06, 2011 at 10:12:39AM +, David Bovill wrote:

 I'd like to be able to use Fossil as data storage for a project I am
 working on, this project will in the future need to work on mobile devices.
 Sqlite is accessible on these devices, would a minimal mobile version of
 Fossil for use as local data storage be feasible?
Fossil is not a library, but rather an executable program.
This is a crucial difference compared to plain sqlite which you simply
can load into your own program and call the API it exposes.

___
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 list commits made so far?

[Konstantin Khomoutov]

On Sun, 6 Nov 2011 09:28:51 -0500
Martin Gagnon eme...@gmail.com wrote:

  wrote: Is there a command that I could run to list all the commits,
  and for each, would show which files were part of the commit?
  fossil timeline -showfiles -n 10
  
  The -n parameter is kind of a kludge there. By default there is a
  limit to how many are shown but there is no way to say no limit,
  so we can just provide a really large number 
 
 I remembre trying n=-1 on web interface to get everything. I don't
 know about command line version... I'll try when I'll have access to
 my computer.. I guess it will need some way to escape the '-'.
May be it worth adding the -all command-line option to
`fossil timeline`?

Actually, I prefer Git's approach to this in which `git log` by default
returns everything, but if it detects it's operating on a TTY it pipes
its output through a $PAGER so the user gets only the $LINES worth of
output by default and then they're free to dig deeper or quit the
pager.  But as it currently stands, -all could be a good addition,
it seems.
___
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] 2 questions

[Konstantin Khomoutov]

On Fri, 04 Nov 2011 13:52:04 +0200
Zeev Pekar z.pe...@gmail.com wrote:

[...]
  It would be impossible to implement within fossil's world view.
  Once i clone a repo i have the whole thing, which i can then
  manipulate (with admin-level rights) on my machine - you cannot
  stop me from checking out a given path once i have access to a
  clone of the repo. There is no mechanism with which fossil can
  completely protect subdirectories unless it explicitly supports
  partial clones (pulling only part of the repo).
 
 Ok, maybe implement partial clones?
I think the way to go would be to have something resembling Git's
submodules.  That is, keep each subproject in a separate repo and
have a way to the commits in the master (intergating or whatever)
repo to reference specific commits in those satellite repos
(submodules).
___
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] Stash and local directory

[Konstantin Khomoutov]

On Thu, 3 Nov 2011 12:50:02 +0100
Lluís Batlle i Rossell virik...@gmail.com wrote:

 I noticed that 'fossil stash save' only saves the files that are
 under the subdirectory I run the command. Shouldn't it save all the
 changed files in the repository?

My v1.20 build says in its `fossil help stash` output:

Save the current changes in the working tree as a new stash.

So looks like you've found a bug.

And I, for one, also think that stashing should affect the whole
working tree unless the user explicitly specified what files they want
to stash.
___
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] Stash and local directory

[Konstantin Khomoutov]

On Thu, 3 Nov 2011 17:58:47 +0100
Stephan Beal sgb...@googlemail.com wrote:

 Save the current changes in the working tree as a new stash.
 So looks like you've found a bug.
 i disagree - the wording there is slightly ambiguous: working tree
 could be interpreted as the entire checkout or tree ==
 subdirectory.
Well, possibly it's my Git mindset chiming in, but I can't recall
that I ever saw anyone using the term working tree to refer to the
current working directory.  The term tree in my eyes refers to the
repository state in a DVCS system.  That is, each commit refers to a
tree, and the current checkout is itself a tree--the working tree.
___
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 Repository Does Not Exist Error

[Konstantin Khomoutov]

On Fri, 28 Oct 2011 13:56:21 +0200
Stephan Beal sgb...@googlemail.com wrote:

   Or if you DO have uncommitted changes you can also try:
  
 rm _FOSSIL_
 
  Dangerous if you have stashed changes ;-)
 
 
 Aha - THAT explains why i lost my stash the last time i did
 that ... ;)

For the record (more for the original poster to read), these things
are documented in [1].

1. http://www.sqlite.org/debug1/doc/trunk/www/tech_overview.wiki
___
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 Repository Does Not Exist Error

[Konstantin Khomoutov]

On Fri, 28 Oct 2011 07:00:41 -0700
Matt Welland estifo...@gmail.com wrote:

 I usually open the _FOSSIL_ file with sqlite3 and update the pointer
 to the repo db. A repodb reset command or some such would be nice
 to have.
fossil switch NEW_LOCATION

That would make Subversion users feel at home.
Though I personally like the name retarget or rebind.
reset sounds a bit too scary.

/bikeshedding
___
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 is Awesome

[Konstantin Khomoutov]

On Tue, 25 Oct 2011 18:51:05 -0700
Caleb Gray ca...@calebgray.com wrote:

[...]
 3) The web interface could use a face lift, as well as some HTML5
 functionality.
 
 I've got a lot of web development experience and would love to
 contribute in this area, also.
 
 All of the work on the JSON APIs is a great step toward making the
 entire interface XHR compatible. What are the community's feelings on
 jQuery? I get the gist that externals are trying to be avoided, so
 that's why I'm asking, I would love to write a library that turns the
 current site in to a highly interactive version without touching the
 HTML or CSS at all.
I strongly disagree.
First, please don't fix what's not broken.
Web UI does what it's intended to do, and does it well. JS usage is
constrained to what can't be done without it (those arrows in the
timeline view), and it's even usable with JS turned off.

P.S.
I'm one of those crazy folks who usually has NoScript turned on except
for the intranet sites, so yes, I'm biased.
___
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] Veracity (was: Fwd: suggestion on fossil)

[Konstantin Khomoutov]

On Thu, 20 Oct 2011 17:28:27 +0200
jos van kesteren josvankeste...@gmail.com wrote:

[...]
 Even that is not necessarily true. You can't merge binary files
 like text files -- sure. But it doesn't mean that for a specific
 binary format, a merge algorithm isn't possible. Consider ODF
 documents for a moment. A merge program could extract the zip
 archive, do a *textual* merge on the XML files and zip the result
 up again. It works well for many use cases.
[...]
 Since ODF documents can be unzipped, and their XML contents are text
 anyway, why not make a commit program (instead of a merge program)
 that unzips the ODF and
 stores the XML in the repo ?
Note that there are some problems:
1) Zipping them back is not that trivial [1] which means you have to
   use specialized uncommit program to properly reassemble such
   containers.
2) ODF container stores several files in several directories,
   so as soon as you unpacked it, it's not just a single file anymore,
   so you have to invent a way to somehow treat the files from this
   container as a single entity when they are stored in a DVCS.
   (And in some or a parallel thread here someone confirmed Fossil
   does only tag commits, not files.)
3) The XML files in ODF containers, while human-readable, are still
   autogenerated.  The XML format is indeed intended to increase
   accessibility of the content, but innocent changes in the document
   from the point of view of the user who made them can result in rather
   interesting changes in the content files.  For instance, ODT
   (spreadsheets), as far as I know, do not allow you to directly attach
   a property to a cell which would indicate that cell has red
   background color; instead the editor will create a special style
   inculding that color info (unless there's no already existing
   matching style) and attach it to that cell.
   By this I'm suggesting that diffing contents of two ODF files using
   only their unpacked contents could not be that straigforward to
   comprehend.

1. http://tanguy.ortolo.eu/blog/article24/
___
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] Locks (Was: Veracity)

[Konstantin Khomoutov]

On Wed, Oct 19, 2011 at 07:41:56PM +0200, Stephan Beal wrote:

 That could even help even before fossil having a capability of
 centraliising locks; the read-only permissions could be enough for
 the people in a team to decide on the locks.
 Can we do read-only cross-platform (i.e. Windows)?
Microsoft filesystems have support for a special file attribute which
controls whether the file should be considered read-only.  It is
advisory.

___
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] target diffwindow - annoying to me

[Konstantin Khomoutov]

On Fri, Oct 14, 2011 at 10:38:37PM +0200, Lluís Batlle i Rossell wrote:

 The timeline links [view] and [diff] use the target=diffwindow (introduced 
 by
 drh in
 http://fossil-scm.org/index.html/ci/6d9bba56dcdcad806a2e8672fe3835d04fad76c2 )
 
 I really dislike the browser opening a new window for that. I'm very used to
 browser's back-forwards, and having that target window there annoys me a lot.
 
 Can't this be solved in CSS or something like that, so anyone can choose his
 flavour? Could we avoid having this hardcoded? I'm not very good at html/css, 
 so
 I can't answer. As for me, I'd have to prepare a new fossil ui setting. :)
 
 What do you think?
Every sensible user knows about shift-click/middle-click for opening
a link in another tab.  So IMO it's not the page author's business to
enforce their policy on the user for the user is able to do it the way
they prefer or find more convenient at the moment.

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

[Konstantin Khomoutov]

On Mon, 10 Oct 2011 15:48:58 +0200
Jan Danielsson jan.m.daniels...@gmail.com wrote:

  FWIW: this could be implemented in JavaScript, using the JSON API
  to fetch the actual diffs, and then laying them out in JS (rather
  than C):
 
  http://fossil.wanderinghorse.net/cgi-bin/fossil-json.cgi/json/diff?v1=b0e9b45baed6f885v2=5f225e261d836287context=5
 
 In my mind, the side-by-side diff shouldn't require javascript. I 
 think it's a good idea to allow sections to be hidden/shown using 
 javascript, but by default the diff should work even with javascript 
 unavailable/disabled or noscript (in firefox) blocking the site. Or
 am I being too old-fashioned?
I'm with you on this.
Your example [1] looks just right to me.
All those flashy JS bells and whistles consistently make me think
they're really there for the sake of being there.

1. 
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cgd.c.diff?r1=1.72r2=1.72.2.1f=h
___
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] What's goning on ? why warnings ?

[Konstantin Khomoutov]

On Thu, 6 Oct 2011 11:27:27 +0200
Lluís Batlle i Rossell virik...@gmail.com wrote:

  [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes
  EDITED src/js/controller/AppController.js
  [ijse@~/Desktop/WorkTable/WatchWizard]$ 
  (exe:6061): Gdk-WARNING **: XID collision, trouble ahead
 
 This output is not from fossil. I bet it's from some X program you
 started in this terminal.
A Gtk program, to be precise.  Probably a web browser.
___
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] GUI client for Windows?

[Konstantin Khomoutov]

On Thu, 6 Oct 2011 11:31:16 -0400
Erlis Vidal er...@erlisvidal.com wrote:

 Take a look to protocol buffers. The implementation is not restricted
 only to java, c++, python. Other people are adding more languages...
 this gives you kind of  portability
Last time I checked GPB was implemented in the form of a C++ library.
I think this is a no-go for Fossil.
I suspect that BSON would be easier to use for this case.

The available C implementation (from MongoDB) is licensed under Apache
License, Version 2.0 so I'm not sure about direct inclusion, but the
spec itself appears to be not so complicated so probably it can be just
implemented specifically for Fossil.

1. http://bsonspec.org/
___
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] GUI client for Windows?

[Konstantin Khomoutov]

On Thu, 6 Oct 2011 18:20:12 +0200
Stephan Beal sgb...@googlemail.com wrote:

  Last time I checked GPB was implemented in the form of a C++
  library.
 Many C++ APIs can be used from C code, actually, as long as their C+
 +-only functionality can be hidden behind an intermediary C-style API.
My point is that we'll need to link against libstdc++ which is not a
problem only on Windows where this library is guaranteed to be
available (in the form of msvcrXYZ.dll files).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] git vs fossil again (was: why you should not shun)

[Konstantin Khomoutov]

On Wed, 5 Oct 2011 18:24:30 +0200
Lluís Batlle i Rossell virik...@gmail.com wrote:

[...]
  And when you find an issue with a commit that is some way back in
  your personal branch it is more logical and easier to review your
  branch if you append the fix to the commit where it belongs
  logically or if you append it at the top of the history
  interspersed with some possibly unrelated changes?
 
 Exactly, these are usual arguments among git lovers.
 
 Nevertheless, git manuals say every commit represents a state of the
 tree. Then you may find logical to expect that every commit log
 talks about a state of the tree. BUT all this goes away, when you
 start using 'rebase'. The commit logs once written do not match
 anymore the 'state of the tree' at the time of commit log writing.
 Assertions in commit logs like this part works may easily not fit
 what was meant at the commit time, for example.
 
 git even comes with 'quick automatic rebase' facilities, that allow
 not rechecking any commit log (a task hard to do, in any case).
 
 Making a review 'easier' by manipulating history can also end up
 being some kind of manipulation to a reviewer. A reviewer may judge
 better by understanding the development.
That sort of we don't need it, we don't need it mantra is a typical
case of the famous Blub paradox.
I mean, if we have two DVCS tools one of which makes you able to
rewrite history and another one which doesn't, the first one is more
powerful _in this particular respect_.  It's as simple as that.
By supporting a feature, the tool does not force you to employ that
feature in your workflow.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] git vs fossil again (was: why you should not shun)

[Konstantin Khomoutov]

On Wed, 5 Oct 2011 11:12:31 -0700
Mike Meyer m...@mired.org wrote:

  That sort of we don't need it, we don't need it mantra is a
  typical case of the famous Blub paradox.
  I mean, if we have two DVCS tools one of which makes you able to
  rewrite history and another one which doesn't, the first one is more
  powerful _in this particular respect_.  It's as simple as that.
  By supporting a feature, the tool does not force you to employ that
  feature in your workflow.
 First, note that there is a difference between rewriting history,
 which is what git supports, and deleting unwanted items, which is
 the request that started this.
Correct.

 Second, that a feature doesn't affect you if you just don't use it
 is a fallacy. Sure, I think history should be sacrosanct, so I won't
 use rebase even if it's available. That doesn't stop others on the
 project (who  don't agree with me) from using it . The only way to
 make sure that doesn't happen is to not have the feature available
 *at all*.
I'm not entirely convinced.
Look at the workflow used by the Git team: they maintain the set of
well known branches, of which the only one, named pu (proposed
updates), is allowed to be rebased and that's actually what happens
with it each time the new release is made--it's cut from the master
afresh.  I mean, while every committer has `git rebase` at their
disposal and knows how it works this does not mean they go off and break
the repository with rebases.  So your point is only really valid when
the project is run by a bunch of idiots or complete newbies.

 Finally, having a feature that powerful available tends to cause the
 API to *not* include safe versions of common tasks that that
 dangerous feature handles. To see what I mean, take a look at
 mercurial, which shares the fossil philosophy, but provides a
 (disabled by default) rebase command. It has a number of commands
 (*not* disabled by default) for tasks that are handled in git using
 rebase. Unlike rebase, those commands are safe, in that mistakes with
 them can't wreck your repo the way a mistake with rebase can. It may
 not make a difference if you never make mistakes, but in that case
 you don't need rebase.
Git handles it from the opposite direction by having the reflog.
But I find this point to be valid, yes, safety nets are a must when it
comes to handling precious data.  BTW I'm a fan of `fossil undo` for
that matter.

 Bottom line: while more features may imply more powerful, it
 doesn't imply better.
Moot point.
I really miss Git's index and `git add --patch` here.
Is Fossil better than Git in this respect by not having those more
features?  Surely it completely is in the eye of the beholder.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] SSL: cannot connect to host www.fossil-scm.org:443

[Konstantin Khomoutov]

On Tue, 4 Oct 2011 17:42:41 +0200
Jiří Navrátil j...@navratil.cz wrote:

 I was going to sync fossil source after long time and I'm getting
 
 fossil sync
 Server:https://myn...@www.fossil-scm.org/fossil
 Bytes  Cards  Artifacts Deltas
 Sent:3086 65  0  0
 /home/navratil/src/fossil/fossil: SSL: cannot connect to host
 www.fossil-scm.org:443 () Total network traffic: 0 bytes sent, 0
 bytes received
 
 telnet www.fossil-scm.org 443
 Trying 67.18.92.124...
 Connected to www.fossil-scm.org.
 Escape character is '^]'.
 
 It worked for me well for long time. I something I have to change?

FWIW,

$ openssl s_client -host www.fossil-scm.org -port 443
CONNECTED(0003)
write:errno=104
$ grep -w 104 /usr/include/asm-generic/errno.h
#define ECONNRESET  104 /* Connection reset by peer */
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] SSL: cannot connect to host www.fossil-scm.org:443

[Konstantin Khomoutov]

On Tue, 4 Oct 2011 18:50:18 +0200
Lluís Batlle i Rossell virik...@gmail.com wrote:

  $ openssl s_client -host www.fossil-scm.org -port 443
  CONNECTED(0003)
  write:errno=104
  $ grep -w 104 /usr/include/asm-generic/errno.h
  #define ECONNRESET  104 /* Connection reset by peer */
 
 It works for me here.
My connect was from 84.204.203.130 if that helps to whoever might be
debugging the server side.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] SSL: cannot connect to host www.fossil-scm.org:443

[Konstantin Khomoutov]

On Tue, 4 Oct 2011 18:50:18 +0200
Lluís Batlle i Rossell virik...@gmail.com wrote:

  $ openssl s_client -host www.fossil-scm.org -port 443
  CONNECTED(0003)
  write:errno=104
  $ grep -w 104 /usr/include/asm-generic/errno.h
  #define ECONNRESET  104 /* Connection reset by peer */
 
 It works for me here.
Hmm, I should note that if I navigate https://www.fossil-scm.org/fossil/
in firefox, it forces me to accept the untrusted certificate and then
proceeds normally--I see the normal fossil index page.
So may be the problem is really rooted in the certificate trust?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why you should not shun

[Konstantin Khomoutov]

On Tue, 4 Oct 2011 14:06:54 -0400
Richard Hipp d...@sqlite.org wrote:

[...]
 (1) Know what you are checking in before you do the check-in.  If I
 had simply paid attention to the size of the *.odp file that I was
 committing, I would have realized that it would be a slow syncer.
Just a thought: what if `fossil status` showed the size of the affected
files?  Something akin to what `vdir` or `ls -l` do but using the
metadata which is to be stored within the fossil repository upon commit.
That would be overkill for `fossil changes` but `fossil status`
already shows extended information so it seems that making it more
extended might turn out to be useful.

[...]
 (3) If you ignore the previous two warnings and find yourself in a bad
 situation, don't panic.  Think about where you are and plan your
 recovery carefully.  If I had panicked, I might have entered other
 Fossil commands which would have purged my undo stack.  As it was, I
 walked away from the keyboard and later realized that a fossil undo
 would get my old files back.
I think this has been discussed already, but to me it appears something
resembling Git's reflog functionality could be of help in the cases
like this one.  The basic idea is to implement a storage (kept in the
checkout database) for things `fossil undo` operates on, but with a
time-based expiration instead of being a stack (Git uses 30 days by
default IIRC).  Conceptually Git's reflog looks just like a single line
of history ordered by time of events forming it.
___
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] [PATCH] IPv6 support and improved reverse proxying support

[Konstantin Khomoutov]

On Mon, 03 Oct 2011 16:00:14 +0530
ashish...@lostca.se (Ashish SHUKLA) wrote:

[...]
 2. IPv6 support. Fossil uses IPv4 sockets by default. I was not sure
 if there was any technical reason to not add support for IPv6, so I
 modified it all relevant places (I was able to find) to use IPv6
 sockets, perform hostname lookups using getaddrinfo(3), accept
 push/pulls to/from IPv6 address, and persist this information in the
 repository database.
[...]

That is cool, but please be sure to make such IPv6 mode not enabled by
default unless it's somehow possible to make it work transparently on a
conventional box with IPv4 only networking.
___
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] [PATCH] IPv6 support and improved reverse proxying support

[Konstantin Khomoutov]

On Mon, 3 Oct 2011 14:39:18 +0200
Lluís Batlle i Rossell virik...@gmail.com wrote:

   2. IPv6 support. Fossil uses IPv4 sockets by default. I was not
   sure if there was any technical reason to not add support for
   IPv6, so I modified it all relevant places (I was able to find)
   to use IPv6 sockets, perform hostname lookups using getaddrinfo
   (3), accept push/pulls to/from IPv6 address, and persist this
   information in the repository database.
  That is cool, but please be sure to make such IPv6 mode not enabled
  by default unless it's somehow possible to make it work
  transparently on a conventional box with IPv4 only networking.
 That's what I saw from the patch at first glance; that building with
 -DWITH_IPV6 fossil required a connected ipv6 stack.
 
 Additionally, I don't know how portable it is to use always
 getaddrinfo (POSIX-2001?) while requiring C89.
Tcl developers recently completed implementing IPv6 in the Tcl runtime,
and Tcl runs even on obscure systems like AIX.  So I think this should
not be a problem these days.  Personally I'm only concerned with this
change not breaking things for the majority of users (who use IPv4 and
will continue to do so in the foreseeable future).

 The code could go right now into a branch, and then we change it
 according to needs and tests.
Good idea, thanks.
___
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] [PATCH] IPv6 support and improved reverse proxying support

[Konstantin Khomoutov]

On Mon, 03 Oct 2011 22:24:02 +0530
ashish...@lostca.se (Ashish SHUKLA) wrote:

  That is cool, but please be sure to make such IPv6 mode not enabled
  by default unless it's somehow possible to make it work
  transparently on a conventional box with IPv4 only networking.
 
 Well, you can enable/disable at compile time. At runtime, it won't
 try to use IPv6 address if you don't have desired connectivity
 available, RFC3484[1] which getaddrinfo(3) implements. But if you
 enable IPv6 support at compile-time, it expects IPv6 support (in
 kernel) to be available at runtime, as it's using AF_INET6 sockets.
Is there no way to make it switchable at runtime (like via `fossil set
ipv6 on`) or is it doable but just complicated to implement?
Having a compile-time switch effectively doubles the number of binaries
one have to built to offer for downloading.  The same issue arises for
downstream distro packagers.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users