Re: [fossil-users] Timeline graph problem on fossil-scm.org

[Lluís Batlle i Rossell]

It looks like two repositories that got commits, and they weren't in
sync. And Jan merged the two leaves without writing about it. 

On Sat, Apr 05, 2014 at 10:55:58AM -0400, Martin Gagnon wrote:
> Hi...
> 
> I've just notice a strange timeline graph on fossil-scm.org and it seems
> to be cause by a hidden tag in the middle of the trunk (or on a fork,
> I'm not sure). 
> 
> If you look on default timeline view:
> 
> http://www.fossil-scm.org/index.html/timeline?y=ci
> 
> The checkin from 2014-04-04 10:20 get a merge that look to come from
> nowhere. (I've tried to follow the line with &n=2000)
> 
> Finally, when pressing on "Unhide" or when looking at the ancestors or
> family of a following checkin:
> 
> http://www.fossil-scm.org/index.html/timeline?p=b37a28228c3788c1fcf026c881eec4017d242dbf&unhide
> 
> It look like that trunk is duplicated (but not quite like a fork).
> 
> I Wonder what it really mean and what can cause that.
> 
> Regards,
> 
> -- 
> Martin G.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil server load control

[Lluís Batlle i Rossell]

On Wed, Mar 12, 2014 at 06:31:29PM +0100, Ramon Ribó wrote:
> > ​
> The current Fossil implementation runs a separate process for each HTTP
> > request.  So an in-memory cache wouldn't be helpful.  It has to be disk-
> > based.
> 
> ​Does not FastCGI do exactly the opposite?​

The current implementation simply uses a fork() per request. Not fork+exec,
which is the common case (CGI) FastCGI is meant to improve.

AFAIU, using a separate process eases the heap memory handling.
___
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] Scalability limits

[Lluís Batlle i Rossell]

On Fri, Feb 07, 2014 at 07:39:37PM +0100, Gour wrote:
> On Fri, 7 Feb 2014 18:40:32 +0100
> Stephan Beal  wrote:
> 
> > It would be really cool to see someone implement their own SCM based
> > on fossil's core artifact model and their own db back-end, though. 
> 
> What about Monotone? Linus was looking at it, but it was too slow at
> that time.

It was a bug of monotone, that slowness. Fixed, for what I remember.

But monotone works on sqlite, if the deal is sqlite.
___
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 info does not report leaf/closed

[Lluís Batlle i Rossell]

On Wed, Jan 29, 2014 at 04:17:38PM +0100, Stephan Beal wrote:
> On Wed, Jan 29, 2014 at 4:13 PM, Stephan Beal  wrote:
> 
> > yes|closed imply a leaf and yes implies opened
> >
> 
> i'm about to be offline for a while but wanted to get this checked in:
> 
> http://www.fossil-scm.org/index.html/info/0b5670dce6
> 
> that uses the yes|no|closed variant.

That'd be enough for me, sure. :)
___
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 info does not report leaf/closed

[Lluís Batlle i Rossell]

On Wed, Jan 29, 2014 at 03:54:22PM +0100, Stephan Beal wrote:
> On Wed, Jan 29, 2014 at 3:52 PM, Stephan Beal  wrote:
> 
> > the "leaf" line currently only appears if it's closed, but i'd go ahead
> > and expand it to (A) appear whenever the current uuid is a leaf and (B) say
> > "open" or "closed".
> >
> 
> for example:
> checkout: d5d7e640d035f1b9aa159fb83eac94fc28862733 2014-01-29 13:35:08
> UTC
> leaf: open

What about "leaf:", with right-side "yes-open", "yes-closed", "no"?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil info does not report leaf/closed

[Lluís Batlle i Rossell]

Hello all,

I think it'd be helpful i "fossil info" would report if the current commit is a
leaf, if it is closed or not, etc.

It seems to report only the "sym-" tags.

I've been confused doing some work, and then finding that I'm ona closed leaf
(already merged to parent branch). :)

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

Re: [fossil-users] Get a checkin diff from cli

[Lluís Batlle i Rossell]

On Wed, Jan 22, 2014 at 06:25:14AM -0500, Richard Hipp wrote:
> On Wed, Jan 22, 2014 at 3:12 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > Hello all,
> >
> > knowing the checkin hash, how can I get in cli the diff introduced by of
> > the
> > checkin? Similar to what appears in the checkin page on the ui.
> >
> 
> I think you have to know both the checkin hash and the parent check-in
> hash.  Then:
> 
> fossil diff --from $parent --to $checkin

Ok, thank you. That is how I was doing it until now, but I thought there should
be "a comfortable way". :)

It'd be nice to have a "fossil diff --checkin X" or so. As for git, I often use
'git show' to achieve that.

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

[fossil-users] Get a checkin diff from cli

[Lluís Batlle i Rossell]

Hello all,

knowing the checkin hash, how can I get in cli the diff introduced by of the
checkin? Similar to what appears in the checkin page on the ui.

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

Re: [fossil-users] 1.28 vdiff changes

[Lluís Batlle i Rossell]

On Fri, Jan 10, 2014 at 10:37:40AM -0500, Martin Gagnon wrote:
> On Fri, Jan 10, 2014 at 04:28:18PM +0100, Lluís Batlle i Rossell wrote:
> > On Fri, Jan 10, 2014 at 10:24:12AM -0500, Martin Gagnon wrote:
> > > On Fri, Jan 10, 2014 at 04:19:19PM +0100, Lluís Batlle i Rossell wrote:
> > > > Hello,
> > > > 
> > > > the Changes page says for 1.28:
> > > > - Enhancements to the "/vdiff" webpage for more difference display 
> > > > options. 
> > > > 
> > > > But what I see, is that it lost the 'Patch' option.
> > > > 
> > > > What are exactly the additional display options?
> > > 
> > > Possibility to hide the diffs or not according to the settings, just
> > > like the /info page.
> > > 
> > > http://fossil-scm.org/index.html/info/74a4db258a
> > 
> > Ah ok. Well... considering also the removal of Patch option,
> > to me this translates almost to "less options in vdiff". :)
> > 
> > Maybe we could have the Patch back?
> 
> I don't know if it ever been on the /vdiff page... I just compile the
> version before the hide diff feature and patch was not there.. 
> 
> May be you confuse with the /info page that still have the patch button.

Ouch! You are right. I run fossil from my branch since years due to
disagreements in features, and I didn't remember that the Patch button was one
of those things. :)

Sorry for the noise.

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

Re: [fossil-users] 1.28 vdiff changes

[Lluís Batlle i Rossell]

On Fri, Jan 10, 2014 at 10:24:12AM -0500, Martin Gagnon wrote:
> On Fri, Jan 10, 2014 at 04:19:19PM +0100, Lluís Batlle i Rossell wrote:
> > Hello,
> > 
> > the Changes page says for 1.28:
> > - Enhancements to the "/vdiff" webpage for more difference display options. 
> > 
> > But what I see, is that it lost the 'Patch' option.
> > 
> > What are exactly the additional display options?
> 
> Possibility to hide the diffs or not according to the settings, just
> like the /info page.
> 
> http://fossil-scm.org/index.html/info/74a4db258a

Ah ok. Well... considering also the removal of Patch option,
to me this translates almost to "less options in vdiff". :)

Maybe we could have the Patch back?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] 1.28 vdiff changes

[Lluís Batlle i Rossell]

Hello,

the Changes page says for 1.28:
- Enhancements to the "/vdiff" webpage for more difference display options. 

But what I see, is that it lost the 'Patch' option.

What are exactly the additional display options?

Thank you,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

[Lluís Batlle i Rossell]

On Thu, Jan 09, 2014 at 04:12:31PM +0100, Remigiusz Modrzejewski wrote:
> 
> On Jan 9, 2014, at 16:00 , Martin S. Weber wrote:
> 
> >> But I want Fossil to follow the latest SQLite alphas, not the latest SQLite
> >> stables.  That's the whole point:  Fossil supports SQLite as a test
> >> platform.  SQLite stable has already been thoroughly vetted and tested and
> >> there is little point in testing it further.  I want Fossil to run with the
> >> latest SQLite on trunk to smoke out bugs early.
> > 
> > ...but fossil in itself is a pretty awesome piece of software, that's 
> > expected
> > by its users to be stable -- at least for releases.
> 
> I second this view, Fossil is definitely valuable on its own merit.
> As such, its stable versions should not contain alpha-quality code from other 
> projects.

As for me, I think that fossil has showed that it works well enough at almost
any trunk checkin. I understand that the named version sqlite has already been
quite tested; a fossil release with it will only mean *more* tests for sqlite.
It sounds good to me.
___
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] Export artifact to archive?

[Lluís Batlle i Rossell]

On Fri, Jan 03, 2014 at 04:36:26PM +, Roy Marples wrote:
> Hi List
> 
> Can fossil create an archive (tarball, zip file, etc) from a given
> artifact id WITHOUT using the web interface?
> Something like this is what I need:
> $ fossil archive ?ID | bzip2 > distribution-version.tar.bz2

Hi,

fossil tarball.

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

[fossil-users] Annotate: when are files added?

[Lluís Batlle i Rossell]

Hello,

it'd be nice if 'annotate' could be told to follow merges.

It seems that it cannot distinguish if a new file came through a merge, or it
was completely new.

So, if you add a file in branch A, and then merge A to B, C, D, ...  annotating
the file in any branch B, C, ... will have the merge checkin as the oldest
source of content.

The same applies to file lines.

I'm lazy to propose a patch though. :)

Regars,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] JSON commit

[Lluís Batlle i Rossell]

Hello,

I'd like to have a json operation to commit files. It is not there yet, right?
There is branch creation, but not any interface to commit.

I'd like to be able to commit (linked to json login), without having a checkout.

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

Re: [fossil-users] ticket management

[Lluís Batlle i Rossell]

On Tue, Oct 15, 2013 at 10:09:41PM +0200, j. van den hoff wrote:
> I'm in the process of giving the ticket system a try for a
> collaboration where we need to keep track of text document changes
> on the one side and have a facility to report problems/issues
> observed with the system (hardware, not software, ...).
> 
> question: the ticket type is predefined to be one of those
> categories given in the drop down menu (code defect etc.). these
> categories don't really match our needs. is there a way to add
> further categories, at least "other" and a free text choice would
> probably be good to have?

Enter in the Admin -> Tickets page. You can tune everything.

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

Re: [fossil-users] Autosync: Too bad git doesn't have it...

[Lluís Batlle i Rossell]

On Wed, Sep 11, 2013 at 11:02:12PM -0700, B Harder wrote:
> I read this roughly (in fossil-speak) as:
> 
> "I had a bunch of email notes from folks requesting I merge their
> feature-branches into my main branch, but my machine crashed and my mail
> isn't accessible…"

I don't read it that way.

Linus was pulling the patches, and archiving them as long as he pull them. But
he didn't push the branch that often, so once the disk broke, mail & upstream
git was desynced.

> On Sep 11, 2013 4:34 PM, "Richard Hipp"  wrote:
> 
> > It appears that autosync would have saved Linus Torvalds from losing some
> > work yesterday.  See
> > http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/01669.html for
> > details.  Bummer.
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> >
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> >

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

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

Re: [fossil-users] Enhancement: commit and close merged leaf

[Lluís Batlle i Rossell]

On Tue, Jul 30, 2013 at 10:45:31AM +0100, Jan Nijtmans wrote:
> 2013/7/30 Lluís Batlle i Rossell :
> > About the code starting at line 1693, it looks to me like it runs in any 
> > case.
> > Does this change only add a new "--integrate", or it also changes the 
> > behaviour
> > of usual merges?
> 
> That code does an additional pass over the vmerge table, in order to
> determine which branches should be closed. Existing merges
> never produce "id=-4" so the query will give the empty result then.

But maybe it should not run unless in 'integrate' mode?
___
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] Enhancement: commit and close merged leaf

[Lluís Batlle i Rossell]

On Tue, Jul 30, 2013 at 10:11:52AM +0100, Jan Nijtmans wrote:
> 2013/7/12 Stephan Beal :
> > On Fri, Jul 12, 2013 at 10:25 AM, Jan Nijtmans wrote:
> >> Well, just try out the "merge-integrate" branch. I would say
> >> the glass is full again.;-)
> >
> > Indeed it is! i like what you've done :)
> 
> I made one additional change: adding states
> UPDATED_BY_INTEGR and ADDED_BY_INTEGR
> (comparable to their XXX_BY_MERGE equivalent)
> in "fossil (status|changes|ls -v)"
> 
> See:
>
> 
> Still no objections, anyone? I think it's ready to be
> integrated into trunk (using "merge --integrate",
> of course), but another round of evaluation never hurts!

Hello all,

I'll try to add some feedback. :)

Why INTEGR, and not INTEGRATE?

There is also case -1, -2, -4. Why not -3?

About the code starting at line 1693, it looks to me like it runs in any case.
Does this change only add a new "--integrate", or it also changes the behaviour
of usual merges?

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

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote:
> 2013/7/25 Richard Hipp :
> > If it does work, then I move for the immediate banishment of all __CYGWIN__
> > macros.
> 
> Doing that will break four things:
> - Accessing a check-out repository on Cygwin, while the previous check-out
>   was done in win32.
> - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil.
> - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of
> UNC paths.
> - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)

As a cygwin user, this breakage is what I expect by any cygwin version of a
program, be it fossil, mercurial, git, vim, ...

I'd never use a cygwin-git checkout with non-cygwin-git, for example. I never
tried and i would not expect it to work.

> > If it doesn't work, is that a bug in cygwin?
> 
> More likely, it's a limitation of Cygwin running on Windows.
> 
> Not seconded.
> 
> In SQLite various __CYGWIN__ #ifdef's can be removed if another locking
> mechanism is put in place. Attached is the current patch the Cygwin
> people use for their build of SQLite accomplishing this. But this only
> works on Cygwin > 1.7.20, and it doesn't follow the SQLite coding
> style, so it will need some more work.

I have no idea how locking has to be handled in cygwin, but if the issue is at
using a sqlite db with both cygwin and non-cygwin programs, this is a tricky
thing.

As for me, I don't expect cygwin programs' data to cope well with windows
programs' data.

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

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote:
> On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon  wrote:
> 
> >  In Theory, fossil should build and work on fossil like on any other unix
> > like Operating system (like linux/*bsd etc..) That's what cygwin is for.
> >
> 
> "grep" tells me that there are 33 instances of the __CYGWIN__ macro in
> Fossil, in 8 different files.  So if you use "sed" to change them all to
> __CYGWIN_OFF_ (or something else harmless) and then do "./configure; make",
> does it work?   (I don't have cygwin installed so this is not something I
> can easily test.)
> 
> If it does work, then I move for the immediate banishment of all __CYGWIN__
> macros.

fossil clone in cygwin64 now works perfectly:
$ sed s/__CYGWIN__/__CYGWIN__OFF__/ -i src/*
$ ./configure
$ make -j4

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

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

On Thu, Jul 25, 2013 at 07:44:16AM -0400, Martin Gagnon wrote:
> Le 2013-07-25 06:43, Jan Nijtmans a écrit :
> >2013/7/25 Richard Hipp  :
> >> Native, pure-blooded windows binaries run just fine on cygwin,
> right?  So
> >> why are we complicating the code with exceptions, special cases,
> and hacks
> >> for cygwin?
> >
> > There are three things that a windows fossil binary can never do
> > in the Cygwin environment:
> > 1) handle Cygwin (Unix) links and mount points
> > 2) setting the Windows file-system case-sensitive (use both "Makefile"
> > and "makefile")
> > 3) use a Cygwin program as commit/stash editor
> >
> > For me personally those 3 things are not important, but apparently
> > (see earlier messages in this thread) for other people it is.
> Unfortunately!
> >
> > I'm trying to find out what the minimum patch is to get the Cygwin build
> > of fossil (both 32-bit and 64-bit) working again, so fossil can be
> > built out-of-the box on Cygwin again. Of course, any feedback
> > is welcome.
> 
> In Theory, fossil should build and work on fossil like on any other unix
> like Operating system (like linux/*bsd etc..) That's what cygwin is for.
> 
> I have the feeling that in some part of the code, cygwin is treated as
> windows and in other place it is treated as unix-like (posix). I guess
> this is the problem.
> 
> I believe that when building for cygwin, it should never goes on any
> #ifdef that are special for windows. So if cygwin really work as
> expected, fossil/sqlite code should not need much exceptions in order to
> work in Cygwin.
> 
> Per example, on native windows we cannot just do "./configure && make",
> we need a special manually maintain Makefile. But on cygwin, it *should*
> work.

This is also my understanding.

And as for "why we need fossil-for-cygwin" from Richard... I think it is almost
the same reason of why we need cygwin. :)

I don't use windows because I like it's UI. When I use windows, I want it the
closest to unix. This means terminals, fds, unix sockets, fork, process groups,
etc. Cygwin is great at building all that over the weird windows OS.

Using a non-cygwin program in cygwin quite breaks the magic (terminal fds not
passing on fork, different filesystem views, paths, permissions, etc.).

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

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

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

If I use windows with *all inside a cygwin terminal* is because I adapt very bad
to unusual environments. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

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

Ah, the point isn't bash; the point is at processes passing properly the fds
for the *terminal*. I guess that once you put a non-cygwin process in the family
tree, the children can't access the terminal ancestor properly.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

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

notepad easier than vim? Not at all, for a brain trained on vim. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

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

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

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

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

Ah ok. Good to know!

Thank you,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

Great! Very informative. Thank you.

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

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

[fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

Hello,

today I built fossil on cygwin64, and it built but "it didn't work". Cloning, a
line in os_win.c complained about not having permission to create a file (a tmp
file with some kind of random string) in C:/windows.

I wonder... why is it running any os_win code? shouldn't cygwin look like unix, 
to
fossil?

I've been using happily fossil in cygwin 32-bit since years, and only today I
tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I am
doing something very wrong.

I tried both the 'configure' makefile, and Makefile.classic.

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

Re: [fossil-users] autosync with fossil merge

[Lluís Batlle i Rossell]

On Fri, Jul 19, 2013 at 07:26:57PM +0200, Stephan Beal wrote:
> On Fri, Jul 19, 2013 at 7:00 PM,  wrote:
> 
> > That way, we are never caught off guard.
> >
> 
> Until there's an unintended fork, then it leads into an area new users
> probably aren't comfortable with - merging and conflict resolution.
> Autosync used to be off by default but in practice we saw unintended forks
> all too often.

We have two use cases: with autosync and without autosync. People can
choose one or the other, no matter the default.

But I think that the 'autosync' case should not mean 'autosync' for only some
commands (update, commit) but not all (merge).

For me autosync means that I can look at the ui of our shared fossil server, and
use local operations based on the information I see in the shared webserver
(considering that there can be races).

I look at the central webserver for branch X, and I know that my local "fossil
update X" will bring me there. But annoys me that I want to merge that branch X
into my current branch, and it silently gets the *local X* (that can be very
outdated), not server's.

Stephan, I understand that you don't like autosync, but I find it very useful.
:)
___
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] autosync with fossil merge

[Lluís Batlle i Rossell]

On Fri, Jul 19, 2013 at 01:43:15PM +0200, Stephan Beal wrote:
> On Fri, Jul 19, 2013 at 11:57 AM, Lluís Batlle i Rossell
> wrote:
> 
> > I think I wrote this before, but I use autosync, and I often end up making
> > a
> > "fossil merge" of a locally-outdated branch. It's quite annoying. :)
> >
> > Should fossil merge autosync before attempting the merge, if autosync is
> > set?
> >
> 
> If it did that then it would do a sync where none is required for the
> majority of cases, and that sync would fail if the user is offline. That
> would force the majority-case user who is offline to turn off autosync
> before doing any merging.

You could say the same about "fossil update" for switching branches, or
committing, and they do autosync. I don't see why "fossil merge" should be
different.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] autosync with fossil merge

[Lluís Batlle i Rossell]

Hello,

I think I wrote this before, but I use autosync, and I often end up making a
"fossil merge" of a locally-outdated branch. It's quite annoying. :)

Should fossil merge autosync before attempting the merge, if autosync is set?

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

Re: [fossil-users] Side-by-side diff improvement

[Lluís Batlle i Rossell]

On Sun, Jul 07, 2013 at 11:49:56AM -0400, Joel Bruick wrote:
> Lluís Batlle i Rossell wrote:
> >I still have to test this scrollbar proposal (I don't like much scrollbars
> >inside windows which already have scrollbars...), but at least it goes into 
> >a good direction.
> 
> Heh, I'm with you 99% of the time on excessive scrollbar hatred, but
> for this situation I think it's really the best way to do it.

It's the style used by meld and those very useful programs, 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] Side-by-side diff improvement

[Lluís Batlle i Rossell]

On Sat, Jul 06, 2013 at 02:34:38PM +0300, Sergei Gavrikov wrote:
> On Fri, 5 Jul 2013, Joel Bruick wrote:
> 
> > Hi all,
> > 
> > I've committed a pretty big changeto the diff
> > code(http://www.fossil-scm.org/index.html/info/4081a91c84) , and I'd
> > like some other people to take a look at it/test it out before it
> > (maybe/hopefully) gets merged into the trunk.
> > 
> > The purpose of this commit is, as the commit message says, to support
> > arbitrary line lengths with synced horizontal scrolling in
> > side-by-side diffs.  Here's an example of it in action on a test copy
> > of the Fossil repo:
> > http://joelface.com/fossil/fdiff?v1=98aec3c55155011b&v2=d74d0c320c455abd&sbs=1(you
> > can click anywhere inside a diff and use the left/right arrow keys to
> > scroll)
>  
> Thank you! I looked for this for months. At the end, sbs diff does not
> "break" long UTF-8 lines
> 
>   
> http://91.208.39.24:8080/lipsum/vdiff?from=6a58f2dd9ada9a81&to=8b0984ab46648f58&sbs=1
> 
> New sbs diff engine with scroll bars looks great (tested on Linux:
> Firefox & Google Chrome). I could not live without it.

In the 'annotate_links' branch, since many months there is a patch that does not
break lines. For us it was inacceptable that a 'diff' could *hide* the
differences, due to some forced wrap length.

It mainly calculated the max line, and took it as the wrap length.

I still have to test this scrollbar proposal (I don't like much scrollbars
inside windows which already have scrollbars...), but at least it goes into a
good direction.

Thank you!
___
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, proxies and SSL, revisited

[Lluís Batlle i Rossell]

On Mon, Jun 17, 2013 at 10:56:03AM -0400, Richard Hipp wrote:
> On Mon, Jun 17, 2013 at 10:48 AM, Brandon Invergo wrote:
> 
> >
> > However, when I attempt to sync my Fossil repositories, I receive the
> > following error:
> >
> > $ fossil sync https://user:p...@repos.invergo.net/reponame
> > via proxy: http://proxy.company.com:8080
> > fossil: server says: 503 Service Unavailable: 0
> >
> 
> I don't know that much about proxies, since I never personally need to deal
> with them.  But maybe they should be disabled for HTTPS?

To use https over an http proxy, fossil should use a CONNECT http proxy
command. After success on that, it's like a normal direct connection to the
remote https server, and all TLS happens without the proxy understanding a word.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Lluís Batlle i Rossell]

On Tue, May 28, 2013 at 09:08:10AM -0400, Richard Hipp wrote:
> Survey:  How many people know that in the web-based timeline for Fossil,
> you can click on any two nodes in the graph and get a diff between those
> two nodes?
> 
> I think this is a very useful feature.  But I'm guessing that not many
> people know it exists.  Please confirm or refute my guess.

I knew, but we rarely use it. What we use all day is the "vdiff to parent
branch" feature implemented in the 'annotate_links' branch. :) We use it all the
time.

That "vdiff to parent branch" fits much better our use case, at a single click.
No need to find versions.

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

Re: [fossil-users] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote:
> On Mon, May 13, 2013 at 10:41 AM, Andy Bradford 
> wrote:
> 
> >
> > When I  first learned  about fossil and  the integrated  tickets/wiki, I
> > assumed that  both of these  features were also version  controlled just
> > like any other might that might exist in the repository.
> 
> 
> The Wiki is version controlled with a DAG, just like code.  But it is a
> separate and independent DAG.  And the current user interface does not give
> you access to the details of the change history.  That UI could be enhanced
> to do that, if there is a need, but in 6 years nobody has complained and so
> it has not yet happened.

And now that there have been complains? :)

Does anyone want to endeavour the task?

I've the feeling that the question had come up before, but simply noone
developed a solution.

Another approach is to say, next year, "in 7 years nobody has complained". ;)
___
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] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Mon, May 13, 2013 at 11:04:23AM +0200, Stephan Beal wrote:
> On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell
> wrote:
> 
> > A simple operation (similar to edit, just with the merge conflicts) could
> > allow
> > merging multiple leaves.
> >
> > What do you think?
> 
> 
> While i'm not at all against the idea of upgrading the wiki pages to
> full-fledged content, i just want to point out that this feature would
> affect more than the www GUI: the (fossil wiki commit) and
> (/json/wiki/save) commands would also be affected by this, and would need
> to be expanded to catch/reject/report merge conflicts. That would be
> relatively easy for (wiki commit), where we can simply exit() on conflict,
> but more work for /json/wiki/save, where the conflict has to be reported
> back to the user along with the conflict-merged data. Such a "non-success"
> case does not fit in with the current "100% success" _or_ "100% failure"
> response model, and the error reporting mechanism does not allow one to
> send a payload back to the client (in this case the conflicted content). So
> i'd need to find a mechanism we could use to report such
> "not-total-failures" which isn't too difficult for clients to work with.

No, I only mean that the wiki pages should report about *multiple leaves*. With
the current artifacts, wiki pages include the 'Parent artifact id', so it should
be already possible to report that. I don't mean that we block any user in any
operation.

Then, we only need an extra operation that could *merge*. Imagine that you click
the "Merge leaves" link; it should offer a text input like with wiki edit, but
with the conflicts inside.

The artifact of the wiki page, then, could include multiple parent artifact id
to mean a merge.
___
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] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 07:28:59AM -0400, Richard Hipp wrote:
> On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > I don't see why most VCS tend (somehow propose) to *not commit* merge
> > conflicts before solving the conflicts. That makes the conflict solution
> > 'disappear' from the timeline.
> >
> 
> One reason: Having non-working code in the tree makes doing a bisect very
> difficult.

In that case, maybe it'd be nice to keep some kind of commit tree also for wiki
pages; a gui should be able to show the multiple leaves, if they happen.
Nowadays, what would be 'multiple leaves' go unnoticed.

A simple operation (similar to edit, just with the merge conflicts) could allow
merging multiple leaves.

What do you think?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] stime and utime

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 09:50:36PM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 9:13 PM, Stephan Beal  wrote:
> 
> > (pushed/popped via start()/stop()), but before i commit it i want to play
> > with start() returning and ID and end() taking an ID, as opposed to
> > requiring matching pairs, e.g.:
> >
> 
> Yeah, i like that better:
> 
> http://fossil-scm.org/index.html/info/e28433a692
> 
> it is not currently exposed via th1, as the OP requested, but it lays some
> generic groundwork for such an addition:

So the th1 addition is the only work left?

Thank you!
___
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] TH1 bomb

[Lluís Batlle i Rossell]

I see the same.

On Wed, May 08, 2013 at 07:02:28PM +0300, Sergei Gavrikov wrote:
> Caught by a chance (try evaluate "info" in TH1 without a sub-command)
> 
>   % ./fossil test-th-eval info ;# bomb (100% cpu/mem usage)
>   Segmentation fault
> 
> Is it reproducible?
> 
> More pain for a server
> 
>   /admin_th1
> 
>   TH1:
>   [info  ]
>   [  ]
>   [  ]
>   [ Run TH1 ]
> 
> Out of memory?
> 
> NOTE: Fossil version below is just for a reference, I do not say that
>   entered something wrong.
> 
>   % ./fossil
>   This is fossil version 1.25 [0264475c4a] 2013-05-08 04:12:07 UTC
> 
> Just in case (if TH1 depends on Tcl)
> 
>   % tclsh
>   % info patchlevel
>   8.5.13
>   % parray tcl_platform
>   tcl_platform(byteOrder)   = littleEndian
>   tcl_platform(machine) = i686
>   tcl_platform(os)  = Linux
>   tcl_platform(osVersion)   = 2.6.32-41-generic
>   tcl_platform(platform)= unix
>   tcl_platform(pointerSize) = 4
>   tcl_platform(threaded)= 1
>   tcl_platform(user)= sg
>   tcl_platform(wordSize)= 4
> 
> 
> Sergei
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 07:28:59AM -0400, Richard Hipp wrote:
> On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > I don't see why most VCS tend (somehow propose) to *not commit* merge
> > conflicts before solving the conflicts. That makes the conflict solution
> > 'disappear' from the timeline.
> >
> 
> One reason: Having non-working code in the tree makes doing a bisect very
> difficult.

Ah, good one.

Maybe then the code doing diffs on a bisect could be clever enough to understand
a merge conflict.
___
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] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 01:01:42PM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 12:56 PM, Lluís Batlle i Rossell 
> wrote:
> 
> > In fact, I don't see why most VCS tend (somehow propose) to *not commit*
> > merge
> > conflicts before solving the conflicts. That makes the conflict solution
> > 'disappear' from the timeline.
> >
> > I think it's fine in committing the conflict marks, and then the solution
> > be an
> > explicit extra checkin. The wiki and tickets could work that way.
> >
> 
> But in the wiki it can't work that way at the moment - they are committed
> as soon as you click save. If we were to do a proper merge at that point we
> would have no choice but to either NOT save the changes (returning to the
> editor with the conflict-marked version), or to save the conflicted
> version. The first option has other side effects (e.g. it would affect
> "fossil wiki commit pageName FILENAME"). In an automated process the second
> option would produce conflicts which probably largely go unnoticed.

There could be some kind "auto-merge-leaves". Would that work?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] stime and utime

[Lluís Batlle i Rossell]

Hello,

why was it choosen that "This page was generated in about 0.187s" shows only
cpu time (utime + stime)? Quite a misleading sentence, to my understanding.

It took me a while to understand why it was taking 5s to get the page, and it
showed "0.1s".

Most of our delays come from fs operations, and they aren't reflected in that
calculation. And I can't find how to get the 'real time' spent in the server.

Can this be done with the current th1?

Thank you!
___
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] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 12:52:17PM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 12:28 PM, Lluís Batlle i Rossell 
> wrote:
> 
> > One thing is not be able to merge; the other is losing information
> > silently.
> > Very annoying.
> >
> 
> It's not lost, per se, but it is (annoyingly) hidden in that case. The main
> www UI doesn't (AFAIR) offer any features for browsing specific versions of
> a page, and offers no diff for wiki pages, so it is not straightforward to
> go find the "lost" data. So yes, it's "effectively" lost, but not "really"
> lost.
> 
> (just thinking out loud...)
> i'm not quite sure we even _could_ sanely manage merge conflicts because
> wiki pages are committed directly without the benefit of a fork-check via
> autosync, which means that two people could commit pages on their repo
> copies and a merge problem could not be detected until the sync with the
> main repo. We would have no choice but to force a fork in that case (and to
> somehow decide which one gets forked, or fork all of them).
> 
> i'm sure nobody would object to someone expanding the wiki bits to take
> part in the tag/branch/merge mechanisms. :)

In fact, I don't see why most VCS tend (somehow propose) to *not commit* merge
conflicts before solving the conflicts. That makes the conflict solution
'disappear' from the timeline.

I think it's fine in committing the conflict marks, and then the solution be an
explicit extra checkin. The wiki and tickets could work that way.
___
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] Wiki-Pages synchronisation

[Lluís Batlle i Rossell]

On Wed, May 08, 2013 at 10:20:07AM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 9:34 AM, Oliver Friedrich  wrote:
> 
> > We now have discovered that wiki-pages seem to be not synchronized, but
> > only always used from the last edit. That leads us to some difficulties,
> > editing a wiki-page on both front-repositories - loss of first edit.
> >
> > How is the best way to handle this missing functionality. How would you
> > approach on this?
> >
> 
> The wiki pages do sync but do not partake in branching/merging - the last
> one wins but all historical versions are still there. There is no www UI
> for diffing between wiki page versions, but the JSON API is capable of
> doing it. Here's an example:
> 
> http://fossil.wanderinghorse.net/wikis/cpdo/?page=cpdo
> 
> (That's a custom wiki front-end using a fossil backend via the JSON API)
> 
> - click on the Timeline tab (near the right)
> - click on the version number of one of the wiki page changes.
> 
> Because the wiki pages are internally the same thing as files, they could
> theoretically be extended to support tagging/branching/etc., but so far
> there has never been any motivation to do so.

Friederich has a very good point on this. In wiki pages or tickets, you can't
never be sure you have lost information in a synchronisation. Information is
dropped silently.

One thing is not be able to merge; the other is losing information silently.
Very annoying.
___
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] Ticket 'subsystem' field?

[Lluís Batlle i Rossell]

On Sun, Mar 24, 2013 at 09:37:41PM +, org.fossil-scm.fossil-us...@io7m.com 
wrote:
> Hello.
> 
> I can set the "subsystem" field of a given ticket to "XYZ" with "fossil
> ticket set X subsystem XYZ", but I can't seem to work out how to
> populate the drop down subsystem menu in the web interface. Is this
> documented anywhere?
> 
> I sort of expected entries to appear there after I'd set the fields of
> a few tickets, but they didn't.

No, they are fixed in the HTML of the "New Ticket" or "Edit Ticket" pages, maybe
through the "Common Ticket" page.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Bad link to 'Add attachment' in timeline

[Lluís Batlle i Rossell]

Hello,

the links to the attachments added are broken in the timeline.
Example:
http://fossil-scm.org/index.html/timeline?u=stephan&c=2013-01-25+17%3A41%3A18&nd&n=2
(Look for "Add attachment" and click the attachment link).

I'm not sure how to fix it. Simply remove %R in these two lines?
http://fossil-scm.org/index.html/artifact/8d368b881c72e53c84c5eb0f6b3e3d0aa879e6ca?ln=1874-1890

Regards,
Lluís.

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

[fossil-users] Rebuild of db required, not notified

[Lluís Batlle i Rossell]

Hello,

I think that the changes in the ticket database in these recent fossil versions
break the db, so a rebuild is required. Otherwise, the ticket pages show a red
error "ticketchg table not present" or something like that.

In the past, fossil used to report those problems with a "please rebuild".
Shouldn't this be one of those cases?

Thank you,
Lluís.

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

[fossil-users] Two database troubles in trunk

[Lluís Batlle i Rossell]

Hello,

we have two database-related troubles running the code (almost) from trunk.

First, in windows boxes (fossil cygwin builds), on autosync we get
-
Autosync:  http://@fossil/cgi-bin/
Error: Database error: database is locked: {UPDATE event SET mtime=(SELECT m1 
FROM 
time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM time_fudge);}
Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 347 bytes sent, 454 bytes received
fossil: Autosync failed
-

We also had those messages in an October fossil version, but fossil retried
until it worked. Now it seems that the 'database is locked' makes fossil fail.

Another problem we have seen... in the fossil web, sometimes we see in the top
of the webpage a message in red saying:
SQLITE_OK: Recovered 35087 frames from WAL file /srv/fossil/sal3d.fossil-wal

Any idea what happens? Is this dangerous?

Thank you,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Broken annotate since trunk 2012-11-15

[Lluís Batlle i Rossell]

On Thu, Mar 14, 2013 at 10:25:46AM -0400, Richard Hipp wrote:
> On Wed, Feb 27, 2013 at 6:09 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > Hello,
> >
> > I think that the change in
> > http://fossil-scm.org/index.html/info/ee33b951a4 broke the
> > annotate in fossil.
> >
> 
> Please try the latest trunk check-in and let me know if it works better for
> you.  http://www.fossil-scm.org/fossil/info/e320f0cd79

I think it works. Perfect! Thank you!
___
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] Broken annotate since trunk 2012-11-15

[Lluís Batlle i Rossell]

On Wed, Feb 27, 2013 at 06:59:39AM -0500, Richard Hipp wrote:
> On Wed, Feb 27, 2013 at 6:09 AM, Lluís Batlle i Rossell 
> wrote:
> 
> >
> > Richard, do you mind taking a look at it, as you know best the change in
> > [ee33b951a4]?
> >
> 
> I'm on travel.  It will be a few days.

Hello Richard,

what do you think about reverting [ee33b951a4], at least until you can look at
it?

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

Re: [fossil-users] Good repository to test scalability of fossil

[Lluís Batlle i Rossell]

On Fri, Mar 08, 2013 at 03:12:24PM +0100, Joerg Sonnenberger wrote:
> On Fri, Mar 08, 2013 at 09:09:56AM -0500, Martin Gagnon wrote:
> > I know someone recently test with the NetBSD port tree, but port tree is a
> > bit less realistic since it contain a incredible huge number of small files
> > with an incredible number of commits.
> 
> http://netbsd.sonnenberger.org
> http://pkgsrc.sonnenberger.org

Nice that you still maintain these!

That reminds me... is there any way that 'clone' gives a % of completion, ETA, 
or so?
___
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] bisect 'test failed'

[Lluís Batlle i Rossell]

On Tue, Mar 05, 2013 at 12:02:21PM -0500, Richard Hipp wrote:
> On Tue, Mar 5, 2013 at 11:57 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > > >
> > > > What does bisect do when you give it a "can't test"?
> > >
> > > Suggest another version to test, and keep on going.
> >
> > Look for 'skip' in git-bisect(1). I think that explains better my idea.
> >
> > Notice that there is a 'git bisect run' error code that the program can
> > return,
> > to indicate 'skip'.
> >
> 
> That documentation doesn't really tell me very much.  But I'll try to come
> up with something.  Just not right now as there are several other issues on
> other projects that need to take priority, and you can easily work around
> this by typing "fossil up next" or "fossil up prev" when you hit an
> untestable check-in.

oh perfect. I didn't know this. Thank you!

(btw, remember that annotate is broken :)
___
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] bisect 'test failed'

[Lluís Batlle i Rossell]

On Tue, Mar 05, 2013 at 05:54:39PM +0100, Lluís Batlle i Rossell wrote:
> On Tue, Mar 05, 2013 at 11:48:13AM -0500, Richard Hipp wrote:
> > On Tue, Mar 5, 2013 at 11:44 AM, Lluís Batlle i Rossell 
> > wrote:
> > 
> > > Hello,
> > >
> > > fossil bisect currently only allows 'good' or 'bad'. Looking for the
> > > introduction of a bug requires also the state of "can't test", because a
> > > checkin
> > > could be so broken that doesn't allow determining if the checkin is 'good'
> > > or
> > > 'bad'.
> > >
> > > Could that 3rd state be introduced? Git allows it easily, for example.
> > >
> > 
> > What does bisect do when you give it a "can't test"?
> 
> Suggest another version to test, and keep on going.

Look for 'skip' in git-bisect(1). I think that explains better my idea.

Notice that there is a 'git bisect run' error code that the program can return,
to indicate 'skip'.

___
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] bisect 'test failed'

[Lluís Batlle i Rossell]

On Tue, Mar 05, 2013 at 11:48:13AM -0500, Richard Hipp wrote:
> On Tue, Mar 5, 2013 at 11:44 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > Hello,
> >
> > fossil bisect currently only allows 'good' or 'bad'. Looking for the
> > introduction of a bug requires also the state of "can't test", because a
> > checkin
> > could be so broken that doesn't allow determining if the checkin is 'good'
> > or
> > 'bad'.
> >
> > Could that 3rd state be introduced? Git allows it easily, for example.
> >
> 
> What does bisect do when you give it a "can't test"?

Suggest another version to test, and keep on going.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] bisect 'test failed'

[Lluís Batlle i Rossell]

Hello,

fossil bisect currently only allows 'good' or 'bad'. Looking for the
introduction of a bug requires also the state of "can't test", because a checkin
could be so broken that doesn't allow determining if the checkin is 'good' or
'bad'.

Could that 3rd state be introduced? Git allows it easily, for example.

Thank you,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The finfo page, and the graph there

[Lluís Batlle i Rossell]

Great explanation, Richard! Thank you a lot!

Part of my confusion was related to me never noticing the 'Full' link at the
top.

Best regards,
Lluís.

On Sat, Mar 02, 2013 at 09:48:01AM -0500, Richard Hipp wrote:
> On Sat, Mar 2, 2013 at 9:03 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > Hello,
> >
> > I never understood quite well the 'finfo' page arrows. Is there any
> > detailed
> > explanation of it, and what the arrows mean?
> >
> 
> Consider two graphs of the same file:
> 
>(1)  http://www.fossil-scm.org/fossil/finfo?name=src/add.c&fco=1
>(2)  http://www.fossil-scm.org/fossil/finfo?fco=0&name=src/add.c
> 
> (1) is the "simplified" graph and (2) is the "full" graph.  The simplified
> graph (1) is shown by default.
> 
> In the simplified graph, each version of a file is shown exactly once, and
> it is shown in the branch where it first appears.  The arrows show the
> progression of versions.  Arrows point from the old version of a file to
> its next derived version.  In example (1), [4f9777f58961d887] is an edit of
> [1560b7c42162a2cb] which is an edit of [c877f19ebec7aa01].
> 
> Sometimes the arrows jump from one branch to another.  This is because a
> file can be carried forward, without change, from one branch to another.  A
> new node only appears in the finfo graph when the file is changed.  So, for
> example [c877f19ebec7aa01] was originally on trunk.  But that version was
> carried forward into the invalid-unicode branch when that branch was
> started.  Later, [c877f19ebec7aa01] was changed into [1560b7c42162a2cb]
> inside the invalid-unicode branch.  When invalid-unicode was merged into
> trunk, the [1560b7c42162a2cb] change was carried forward into trunk when
> invalid-unicode was merged, but no new node appears on the finfo graph
> because the add.c file was not modified by this merge.  Later still, the
> add.c file was changed again from [1560b7c42162a2cb] to [c877f19ebec7aa01]
> while on trunk.
> 
> The full graph (2) shows every occasion where a particular instance of the
> add.c file appears in any check-in and in any branch.  You can see that
> [1560b7c42162a2cb] first appeared in invalid-unicode, but later also
> appeared in other branches ticket-d17d6e5b17, trunk,
> convert_before_commit_v2, and improve_commit_warning.  Merge arrows are
> used to show that these are all exactly the same file, that just happened
> to be used in multiple places.
> 
> Key point:  The simplified finfo graph shows only the first occurrence of
> any particular file version.  When a file version first appears in a branch
> and is only later merged into trunk, the node for the file appears on a
> branch in the finfo graph.
> 
> 
> >
> > I've the feeling that the last file change in "trunk" there appearing,
> > does not
> > mean it's the last state of the file in last "trunk", and that always
> > confused
> > me.  Can it be?
> >
> > Regards,
> > Lluís.
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> 
> 
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org

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

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

[fossil-users] The finfo page, and the graph there

[Lluís Batlle i Rossell]

Hello,

I never understood quite well the 'finfo' page arrows. Is there any detailed
explanation of it, and what the arrows mean?

I've the feeling that the last file change in "trunk" there appearing, does not
mean it's the last state of the file in last "trunk", and that always confused
me.  Can it be?

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

[fossil-users] Why the Comment display changed?

[Lluís Batlle i Rossell]

Hello,

usually, the checkin comments were rendered without 'wiki block style' in the
timeline, and *with* 'wiki block style' in the 'info' page.

After this change, the user has to choose to have either all block-style,
none-blockstyle. Is this intended? I'd prefer the "timeline-block-markup"
only to play a role in the *timeline*.

The important change looks like this one:
http://fossil-scm.org/fdiff?v1=dae0af04973d3158&v2=650da8d382a37ae6

Anyone else considers that this is a bug?

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

Re: [fossil-users] Side-by-side diff and non-English text

[Lluís Batlle i Rossell]

On Thu, Feb 28, 2013 at 11:33:18AM +0300, Sergei Gavrikov wrote:
> On Wed, 27 Feb 2013, Joe Mistachkin wrote:
> > 
> > Sergei Gavrikov wrote:
> > > 
> > > Has anyone seen a "broken" output on the side-by-side diff pages for
> > > non-English texts? 
> > > 
> > 
> > Do you have an example that is viewable online?
> 
> Find, please, a test
> 
>   http://chiselapp.com/user/sg/repository/pangrams
> 
> Look at side-by-side diff views from 2nd to 3rd check-in and from 3rd to
> 4th.
> 
> For example
> 
>   
> http://chiselapp.com/user/sg/repository/pangrams/fdiff?v1=edab872a806e8d4c&v2=6936fca46ff9d180
> 
>   Left-side hunk: 30
>   Right-side hunks: 29, 81, 126, 137
> 
> Of course, unified diff has no such quirks.

I consider this a bug. :)

Thank you. I'll report if I find time to take a look at it.

> > > If such an issue exists and it is a limitation the sbs's algorithm,
> > > what do you think, Is it good idea to add new Fossil setting to
> > > manage the default behavior the sbs for vdiff, fdiff, and
> > > time-line's on-click events, i.e.  set sbs=1 or sbs=0 by a
> > > request/setting? 
> > >
> > 
> > Personally, I think it might be nice to have such a setting, even if
> > the side-by-side diff works perfectly for all cases.
> 
> For now, I patch only 4-lines to get sbs=0 by default
> 
>  info.c |6 +++---
>  timeline.c |2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> But perhaps, I missed other places.
> 
> Sergei
> 
> > --
> > Joe Mistachkin
> > 
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> > 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Odd problem syncing to fossil repo

[Lluís Batlle i Rossell]

On Wed, Feb 27, 2013 at 02:12:21PM +0200, Ron Aaron wrote:
> When I disable my machine's firewall I have the same problem.
> 
> But  all my other fossil repos (against my own server) don't have
> the problem.
> 
> I don't understand why the main fossil repo would have any issues,
> since it's all http, and most of the to-and-fro works.  Also, I can
> do a "clone" successfully.

Can you ensure that the server fossil isn't segfaulting?

> On 02/26/2013 08:48 PM, Stephan Beal wrote:
> >On Tue, Feb 26, 2013 at 7:30 PM, Ron Aaron  >> wrote:
> >
> >The weird thing is this happens on a specific machine of mine, but
> >I never have seen this problem on other machines.
> >
> >
> >Local firewall?
> >
> 

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

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

[fossil-users] Broken annotate since trunk 2012-11-15

[Lluís Batlle i Rossell]

Hello,

I think that the change in http://fossil-scm.org/index.html/info/ee33b951a4 
broke the
annotate in fossil.

We use annotate a lot, but as many know, we don't use trunk, but the
"annotate_links" branch, that I update only from tie to time. That's why I only
noticed now the issue from November.

Here is an example situation: let's annotate 'diff.c' in the checkin
[ee33b951a4]. With fossil of of trunk and [ee33b951a4], let's look at the line:

  compute_direct_ancestors(cid, iLimit);

it says to be written by:
587dd57fe1 2012-02-10  martin.weber:   compute_direct_ancestors(cid, iLimit);
(http://fossil-scm.org/index.html/annotate?checkin=ee33b951a4063e33&filename=src/diff.c)

But it's neither a trunk checkin, neither the merge of this branch 'msw-docco'
changes these lines once merged into trunk:
http://fossil-scm.org/index.html/timeline?f=587dd57fe194af81

If we use the fossil version parent of [ee33b951a4], [dac6424e66a82], we see the
line properly annotated with the trunk checkin:
e161670939 2011-10-19   drh:   compute_direct_ancestors(cid, iLimit);

Richard, do you mind taking a look at it, as you know best the change in
[ee33b951a4]?

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

[fossil-users] Bad error in case of db locked

[Lluís Batlle i Rossell]

Hello,

I've just tried to commit while I was running another commit in another shell,
and fossil told me such a misleading message :)

Maybe it can be improved.


Autosync: 
fossil: SQL error: database is lockedeceived: 0

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


Regards,
Lluís.

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

[fossil-users] The checkin comment in the info page

[Lluís Batlle i Rossell]

Hello,

the checkin "Comment:" in the info web page used to be formatted like a wiki. 
Now it
appears formatted as in the timeline. Thus, no newlines, no '', ...

Is this intended? I preferred the old way.

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

Re: [fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

On Thu, Feb 21, 2013 at 02:13:14PM +0400, Konstantin Khomoutov wrote:
> On Thu, 21 Feb 2013 10:28:52 +0100
> Lluís Batlle i Rossell  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.

I find this behaviour reasonable:
If the url had a username, it could ask for a password. And in any case, if the
rights aren't ok to fetch the info, it should fail.

I'd make it work with the 'timeline' or 'clone' permission flags.
___
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

[Lluís Batlle i Rossell]

On Thu, Feb 21, 2013 at 10:24:27AM +0100, Stephan Beal wrote:
> On Thu, Feb 21, 2013 at 8:33 AM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> 
> > IOW, that shell pipeline was just an example demonstrated to you, so
> > don't be too attached to the fact it requires a shell.
> >
> 
> 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. :)
Just to make the command a bit more useful. The go tool will use it for 'ping'
basically, though.

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

Re: [fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

On Thu, Feb 21, 2013 at 11:33:42AM +0400, Konstantin Khomoutov wrote:
> 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).

I know how a shell code does the piping using syscalls. It looked to me that
Stephan wasn't proposing to use fork/pipe/exec/dup though, but a shell 
single-liner.

And as I mentioned before, this is a huge change in the go vcs.go code.

> 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.

If all other VCS can be supported in 100 lines, and adding fossil requires
adding 200 lines, it's not about making anything modular.

When 80% of the code involved (20% = run commands, 80% = http GET, mkdir,
piping, grep) is ONLY for fossil, I can't call it "modular". It will be just a
lot of code that will be used ONLY for one target, no matter how I make it look
like "it will work for any VCS similar to fossil too". :)

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

[fossil-users] Password asked per push

[Lluís Batlle i Rossell]

Hello all,

can I set the remote in some way, so my upstream password isn't stored to disk,
but the url and the username are so? I'd like the password to be asked per push
or sync command.

I'd feel safer and more comfortable this way, when I have a local repository
in computers under not only my control.

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

Re: [fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

On Wed, Feb 20, 2013 at 11:20:18PM +0100, Stephan Beal wrote:
> On Wed, Feb 20, 2013 at 11:18 PM, Lluís Batlle i Rossell
> wrote:
> 
> > I will try to do all the new code required for that, but I doubt it will be
> > accepted easily. And the lack of the command to check an upstream server
> > will
> > also make my patch look even worse, compared to the code that was there.
> >
> 
> Would a new page, e.g. /ping, which simply returns HTTP 200 and no content
> (or a single line, like "ok") suffice?

It has to be something that the 'fossil' command can run alone, and return
a good or a bad errorcode depending on upstream being a fossil repository or
not.

Thank you,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

On Wed, Feb 20, 2013 at 11:18:35PM +0100, Stephan Beal wrote:
> On Wed, Feb 20, 2013 at 9:57 PM, Lluís Batlle i Rossell 
> wrote:
> 
> > 2) and if there were a way to check if an upstream repository answers
> > correctly, other than by cloning into a file:
> >   fossil remoteinfo http://blabla.org/
> >   # ^ Error if the other side isn't a fossil repository
> >
> 
> As a workaround for this lacking feature (which sounds like a good one to
> me), the json API could be used to see if a URL is-a fossil server
> (assuming json's enabled on the remote):
> 
> stephan@tiny:~/cvs/fossil/fossil/src$ wget -q -O /dev/stdout
> http://fossil.wanderinghorse.net/repos/cson/index.cgi/json/HAI | grep -q
> '"timestamp":' && echo OK
> OK || echo NOK
> 
> If it's not enabled:
> 
> 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

Hello Stephan,

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. :)

('We' as a shortcut for what I suppose will be the answer of the go community:
we will first not support fossil, instead of depending on multiplatform code for
shell interpreters. Not that I'm representative of anything around go)

Thank you,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

On Wed, Feb 20, 2013 at 05:00:13PM -0500, Richard Hipp wrote:
> On Wed, Feb 20, 2013 at 3:57 PM, Lluís Batlle i Rossell 
> wrote:
> 
> > 1) there were a way to clone+checkout at once into a subdirectory:
> >   fossil clonedir http://blabla.org/ blabla
> >   # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out
> >   # the .repository.fossil, for example
> >

> mkdir blabla
> cd blabla
> fossil clone http://blabla.org/ .repo
> fossil open .repo

Sure, I know. But this requires issuing those orders in a shell, and that means
writing per-platform go code, instead of a simple 'universal' exec.Cmd. Because
Windows may have cmd, command, ... Others may have flavours of 'sh', ...

If not using a shell, 'cd' will affect the working directory of the process, or
has to be done after forking, before execing fossil, ...

This is already much more complicated than what has been required until now.

Imagine you have a C program, and no shell. The formula that worked for the
other VCS just doesn't work for fossil.

I will try to do all the new code required for that, but I doubt it will be
accepted easily. And the lack of the command to check an upstream server will
also make my patch look even worse, compared to the code that was there.

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

[fossil-users] Making the go tool support fossil

[Lluís Batlle i Rossell]

Hello,

I'm trying to add fossil support to the 'go tool', as it supports other VCSs:
http://golang.org/cmd/go/#hdr-Remote_import_path_syntax

Adding fossil supprt requires lots of changes, due to a lack of similarity with
the other VCS supported. The current code is not flexible enough, and I think
that some of the pieces it requires from the VCS would be nice to have in
fossil.

Specifically, these things would be much easier if:
1) there were a way to clone+checkout at once into a subdirectory:
  fossil clonedir http://blabla.org/ blabla
  # ^ It creates blabla/, blabla/.repository.fossil, and in it, checks out
  # the .repository.fossil, for example
2) and if there were a way to check if an upstream repository answers
correctly, other than by cloning into a file:
  fossil remoteinfo http://blabla.org/
  # ^ Error if the other side isn't a fossil repository

The point '2' is important because go uses some kind of addresses without the
front protocol: blabla.org/repo for example. And then it uses the required
"command 2" to test different modifiers:  http://, https://, ... Currently I've 
no
way other than cloning (and this requires creating a file!) to test the future
client sync.

The currently supported VCS have a way to run these commands: bazaar, git,
mercurial, subversion.

Is there any chance that fossil gets into that shape? Even if partially?
Otherwise the 'go' patch just to support fossil will be a so big rework, that
will be much harder to be accepted.

As a note, here is the current vcs handling code:
http://golang.org/src/cmd/go/vcs.go

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

Re: [fossil-users] Change the CSS

[Lluís Batlle i Rossell]

On Wed, Feb 20, 2013 at 09:54:49AM -0500, Richard Hipp wrote:
> On Wed, Feb 20, 2013 at 9:50 AM, Lluís Batlle i Rossell 
> wrote:
> 
> > On Sun, Feb 17, 2013 at 03:43:35PM +0100, Lluís Batlle i Rossell wrote:
> > > what is the usual process of updating the CSS?
> > >
> > > I see in /setup_editcss that the text editable is not the same as the
> > 'default'
> > > below. I click "Revert to Default", and the editable text is still
> > different.
> > >
> > > I also see that the default header picks "style.css?default". It looks
> > like, by
> > > default, it doesn't get the CSS defined in the text control, but the
> > default
> > > CSS.
> > >
> > > So, in order to get a modification over the default CSS, how to proceed?
> >
> > Oh, I see the trouble! In style.c, there are hardcoded CSS parts. And they
> > are
> > emitted *after* the normal css.
> >
> 
> Those hardcoded parts are the defaults and are only inserted if you omit
> alternatives from the user-specified CSS.

Ah, I've seen that if I add one with the same element naming, the default is not
emitted anymore.

I find it quite a weird and unexpected behaviour, for a person that only has
seen the CSS Admin page. :)
___
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] Change the CSS

[Lluís Batlle i Rossell]

On Sun, Feb 17, 2013 at 03:43:35PM +0100, Lluís Batlle i Rossell wrote:
> what is the usual process of updating the CSS?
> 
> I see in /setup_editcss that the text editable is not the same as the 
> 'default'
> below. I click "Revert to Default", and the editable text is still different.
> 
> I also see that the default header picks "style.css?default". It looks like, 
> by
> default, it doesn't get the CSS defined in the text control, but the default
> CSS.
> 
> So, in order to get a modification over the default CSS, how to proceed?

Oh, I see the trouble! In style.c, there are hardcoded CSS parts. And they are
emitted *after* the normal css.

Shouldn't the whole CSS be configurable?

Additionally, the CSS admin page is a bit confusing, because it shows uneditable
text as 'Default' below, without distinction from the editable.

Specifically, I wanted to change the table.report style. Any ideas?

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

Re: [fossil-users] Feature requests: fossil ui and server improvements

[Lluís Batlle i Rossell]

On Wed, Feb 20, 2013 at 09:40:27AM -0500, Richard Hipp wrote:
> On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom  wrote:
> 
> > Stephan Beal  writes:
> >
> > > There is also no reason to prohibit text-based browsers. i'm not aware of
> > > any which support JavaScript, meaning that they will be severely
> > castrated
> > > when using fossil, but it would be wrong to prohibit them just because
> > X11
> > > isn't running.
> >
> > Links[1] supports at least some Javascript.  Not sure how well--I've
> > only ever used it on the couple of occasions I've needed to SSH from
> > work to my home computer and fiddle with the web interface on the
> > wireless point.
> >
> > [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29
> >
> 
> Interesting.  I never thought to try that, but it does work.  I did this:
> 
>sudo apt-get install lynx
>fossil setting web-browser lynx
>fossil ui
> 
> ... and it works!  You don't see the timeline graph (of course) and the
> side-by-side diff display doesn't work, but a lot of things do work.

I've used it several times; I recall there were some issues about the spawn of
the text browser, but I can't remember now.

And I think elinks is more clever than links, for javascript, iirc. I use elinks
most, among textmode browsers.

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

[fossil-users] Change the CSS

[Lluís Batlle i Rossell]

Hello,

what is the usual process of updating the CSS?

I see in /setup_editcss that the text editable is not the same as the 'default'
below. I click "Revert to Default", and the editable text is still different.

I also see that the default header picks "style.css?default". It looks like, by
default, it doesn't get the CSS defined in the text control, but the default
CSS.

So, in order to get a modification over the default CSS, how to proceed?

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

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

On Tue, Feb 12, 2013 at 07:49:34PM +0100, Lluís Batlle i Rossell wrote:
> I built a new fossil, cloned the fossil repository, and looked at the tickets.
> They don't have comments. I'm a bit confused why we don't see the same in
> this simple case.

Ok, I've just pushed a fix for what I see. I wonder how it was working for you:
http://fossil-scm.org/index.html/info/9cca9398ab

Feel free to rewrite it or revert it, if you think it's not convenient.

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

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

On Tue, Feb 12, 2013 at 07:38:38PM +0100, Lluís Batlle i Rossell wrote:
> On Tue, Feb 12, 2013 at 01:23:46PM -0500, Richard Hipp wrote:
> > On Tue, Feb 12, 2013 at 1:21 PM, Lluís Batlle i Rossell 
> > wrote:
> > I do not know why this is not working for you.
> 
> Ah ok. I've tried a new clone of fossil, and in the new clone it works.
> In three repositories I have, I see the missing 'oldstyle' comments. But how 
> is
> it that I see the effect only after 'rebuild'? If it's related to rebuild, 
> what
> can it be? Is th1 code run at rebuild?

Oh, I was just wrong in this test. I was cloning using an old fossil (thus the
rebuild was done by an old fossil).

I built a new fossil, cloned the fossil repository, and looked at the tickets.
They don't have comments. I'm a bit confused why we don't see the same in
this simple case.

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

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

On Tue, Feb 12, 2013 at 01:23:46PM -0500, Richard Hipp wrote:
> On Tue, Feb 12, 2013 at 1:21 PM, Lluís Batlle i Rossell 
> wrote:
> 
> >
> > If I don't rebuild the database, the comments appear fine. If I rebuild,
> > they
> > don't appear.
> >
> > Does this match the situation? Because it seems to me unrelated to the
> > 'view
> > ticket page'. Maybe I just imagine wrong how ticket pages get composed. :)
> >
> 
> Both SQLite and Fossil contain many legacy tickets (w/o the new icomment
> field) and a few newer tickets that include the icomment field.  When I
> rebuild those repositories, I see all comments - both the legacy +comment
> comments and the newer icomment comments.  This is with the default setup.
> 
> I do not know why this is not working for you.

Ah ok. I've tried a new clone of fossil, and in the new clone it works.
O
In three repositories I have, I see the missing 'oldstyle' comments. But how is
it that I see the effect only after 'rebuild'? If it's related to rebuild, what
can it be? Is th1 code run at rebuild?

I keep on trying to find this out :)
___
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] Ticket changes and mimetype

[Lluís Batlle i Rossell]

On Tue, Feb 12, 2013 at 12:41:47PM -0500, Richard Hipp wrote:
> On Tue, Feb 12, 2013 at 12:23 PM, Lluís Batlle i Rossell
> wrote:
> 
> > On Tue, Feb 12, 2013 at 12:16:23PM -0500, Richard Hipp wrote:
> > > On Tue, Feb 12, 2013 at 11:50 AM, Lluís Batlle i Rossell
> > > wrote:
> > >
> > > Both +comment and icomment are supported in the latest code.  If you are
> > > running a recent Fossil (that you have compiled yourself from sources)
> > and
> > > you load the latest ticket schema and scripts, then rebuild, all of your
> > > comments should be preserved.  At least they are for me.
> >
> > Humm here all "+comment" don't appear in the ticket page, using
> > [a1d2cd84b8].
> >
> > I build fossil (make fossil), I rebuild (./fossil rebuild), and show the UI
> > (./fossil ui). And for me the fossil tickets don't have any comments
> > "+comment".
> >
> > Can you double check? I just doublechecked with a make clean in the
> > middle, with
> > the same outcome.
> >
> 
> The code to display legacy +comment fields is here:
> 
> http://www.fossil-scm.org/fossil/artifact/e736285953?ln=484-495
> 
> Note that the block of code above is part of the default "View Ticket Page"
> script.  If you have modified your "View Ticket Page" to contain different
> code, then your modifications might not be showing the legacy +comment
> fields.

If I don't rebuild the database, the comments appear fine. If I rebuild, they
don't appear.

Does this match the situation? Because it seems to me unrelated to the 'view
ticket page'. Maybe I just imagine wrong how ticket pages get composed. :)

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

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

On Tue, Feb 12, 2013 at 12:16:23PM -0500, Richard Hipp wrote:
> On Tue, Feb 12, 2013 at 11:50 AM, Lluís Batlle i Rossell
> wrote:
> 
> Both +comment and icomment are supported in the latest code.  If you are
> running a recent Fossil (that you have compiled yourself from sources) and
> you load the latest ticket schema and scripts, then rebuild, all of your
> comments should be preserved.  At least they are for me.

Humm here all "+comment" don't appear in the ticket page, using [a1d2cd84b8].

I build fossil (make fossil), I rebuild (./fossil rebuild), and show the UI
(./fossil ui). And for me the fossil tickets don't have any comments "+comment".

Can you double check? I just doublechecked with a make clean in the middle, with
the same outcome.

> Note also that nothing is ever "lost".

Yes sure, I know. :)

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

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

To reproduce it, just use the 'fossil' repository, and rebuild it. Look how no
tickets have comments anymore.

A random example of ticket with comments:
http://fossil-scm.org/index.html/tktview?name=47d4e76139

Try it in a rebuilt repository.

On Tue, Feb 12, 2013 at 05:56:40PM +0100, Lluís Batlle i Rossell wrote:
> Sorry, I said 'mimetype' because it's the first thing I saw. But I see the
> whole ticket "+comment" kind of artifact disappeared, and "icomment", "login",
> ... are used instead.
> 
> So, my guess is that "+comment" kind of tickets are ignored now, at ticket
> contents composition.
> 
> I just can't find that code now, to propose a patch. :)
> 
> On Tue, Feb 12, 2013 at 05:50:18PM +0100, Lluís Batlle i Rossell wrote:
> > Hello,
> > 
> > having a repository with ticket 'append' artifacts without "mimetype" 
> > doesn't
> > work well with fossil trunk ([a1d2cd84b8]).
> > 
> > This is the case of many old 'append' artifacts, and also the case of new
> > artifacts if the "Edit Ticket" page isn't updated to add the mimetype.
> > 
> > I think that any lack of mimetype should be considered html, and compose
> > the final ticket page normally.
> > 
> > Regards,
> > Lluís.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

Sorry, I said 'mimetype' because it's the first thing I saw. But I see the
whole ticket "+comment" kind of artifact disappeared, and "icomment", "login",
... are used instead.

So, my guess is that "+comment" kind of tickets are ignored now, at ticket
contents composition.

I just can't find that code now, to propose a patch. :)

On Tue, Feb 12, 2013 at 05:50:18PM +0100, Lluís Batlle i Rossell wrote:
> Hello,
> 
> having a repository with ticket 'append' artifacts without "mimetype" doesn't
> work well with fossil trunk ([a1d2cd84b8]).
> 
> This is the case of many old 'append' artifacts, and also the case of new
> artifacts if the "Edit Ticket" page isn't updated to add the mimetype.
> 
> I think that any lack of mimetype should be considered html, and compose
> the final ticket page normally.
> 
> Regards,
> Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Ticket changes and mimetype

[Lluís Batlle i Rossell]

Hello,

having a repository with ticket 'append' artifacts without "mimetype" doesn't
work well with fossil trunk ([a1d2cd84b8]).

This is the case of many old 'append' artifacts, and also the case of new
artifacts if the "Edit Ticket" page isn't updated to add the mimetype.

I think that any lack of mimetype should be considered html, and compose
the final ticket page normally.

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

Re: [fossil-users] cannot find a common ancestor between the current checkout

[Lluís Batlle i Rossell]

On Sun, Feb 03, 2013 at 12:59:08PM +0800, Daniel YC Lin wrote:
> I don't know why my repository become two track?
> How to solve this?

Have you run fossil sync before that? Are you sure you have dd76 locally?

> $  fossil stat
> 
> repository:   /home/dlin/fs/abs.fossil
> local-root:   /home/dlin/prj/nextvod/src/abs/
> checkout: 0cf4b729c29643e5a8e7793e7328693b964edb7d 2013-02-03 04:42:51
> UTC
> parent:   627d55889819db66d6bea82b529eee061d906ae6 2013-02-02 05:24:31
> UTC
> tags: trunk
> comment:  for install [base] packages (user: dlin)
> 
> $ fossil merge dd76
> 
> fossil: cannot find a common ancestor between the current checkout and dd76

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

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

Re: [fossil-users] Proper use of "revert"

[Lluís Batlle i Rossell]

On Wed, Jan 30, 2013 at 02:48:33PM -0800, Arnel Legaspi wrote:
> Hello -
> 
> Yesterday I needed to revert back a commit involving 2 files to its parent
> commit.
> The working copy was at the tip (1255785c96) and I needed to get back to
> revision 4002407825.
> When I tried running "fossil revert -r 4002407825" I got the following
> error:
> 
> fossil: the --revision option does not work for the entire tree
> 
> What did the trick was "fossil merge --backout 1255785c96" which is
> strange, since this is not a merge.
> The timeline UI for this particular repo shows a straight line graph.
> 
> Shouldn't the 'revert' command act the way I was looking for? The help
> message does state
> "Revert all files if no file name is provided." What am I missing?

Reverts removes changes in your *working directory*. It's not about "reverting
code already checked int".

You want 'fossil merge -backout' I guess. The help for merge explains better.

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

Re: [fossil-users] howto `grep' through old revisions

[Lluís Batlle i Rossell]

On Tue, Jan 29, 2013 at 08:59:19AM +0100, Gilles wrote:
> On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland
>  wrote:
> >Sorry, didn't paste in the second grep:
> 
> Thanks for contributing this work-around. I guess it shows that
> there's a need for an easy, integrated grep to find code in the
> repository.

Well, at least for me, it's very important to be able to grep wiki pages and
specially tickets too. I think 'export'  won't work, right?

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

Re: [fossil-users] howto `grep' through old revisions

[Lluís Batlle i Rossell]

On Mon, Jan 28, 2013 at 11:01:32AM +0100, Gilles wrote:
> On Mon, 28 Jan 2013 10:43:19 +0100, Lluís Batlle i Rossell
>  wrote:
> >> What do you mean by "deconstruct"? Checking files out?
> >
> >As this question goes to me...
> >$ fossil help deconstruct
> 
> Thanks. After running "deconstruct", do you just grep through all the
> files, regardless of whether they contain actual code or just the
> output from "artifact"?

Grep all files

> Is there a way to avoid writing all those files to disk, and just
> output data to STDOUT and read this with grep?

I don't know how to do that.

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

Re: [fossil-users] howto `grep' through old revisions

[Lluís Batlle i Rossell]

On Mon, Jan 28, 2013 at 10:21:03AM +0100, Gilles wrote:
> On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp
>  wrote:
> >On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell 
> >wrote:
> >> On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote:
> >> >
> >> > Since this thread is a bit long, I'd like to ask: At this point, what
> >> > is the solution to find a piece of code that can be in any revision in
> >> > any file in the repository?
> >>
> >> As I said early in the thread, deconstruct + grep. :)
> 
> What do you mean by "deconstruct"? Checking files out?

As this question goes to me...
$ fossil help deconstruct
___
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] Strange fossil use (multiple leaves)

[Lluís Batlle i Rossell]

On Sat, Jan 19, 2013 at 02:01:56PM +0200, John Found wrote:
> As long as the merge command works on the current checkout, you can do any 
> number of merges and then make a "commit". The result should be something 
> similar.
> 

But why would someone merge the leave, the previous commit, and also its
previous commit?

Maybe because of a merge without committing, once trunk gets a new checkin,
merge again, then again the same, until at the end you commit?

I quite don't get why would someone do that, though :)

> On Fri, 18 Jan 2013 17:48:59 +0100
> Lluís Batlle i Rossell  wrote:
> 
> > Hello,
> > 
> > looking at the tcl timeline, I've just seen a checkin like this:
> > http://core.tcl.tk/tcl/timeline?f=3c4edc83aae0e671
> > 
> > What is that kind of usage? I feel strange that the "merge trunk" has arrows
> > from *3 trunk leaves*, and *2 more checkins* from one of the trunk branches.
> > 
> > What have they typed to achieve that merge? Why do they have multiple 
> > 'trunk'?
> > 
> > I've no idea of how tcl development works, but I'd like to know what fossil
> > usage pattern they use.
> > 
> > Regards,
> > Lluís.
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> 
> 
> -- 
> John Found 
> http://asm32.hopto.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] A warning on 'undo'

[Lluís Batlle i Rossell]

On Fri, Jan 18, 2013 at 11:46:50AM -0500, sky5w...@gmail.com wrote:
> When in doubt, I run:
> fossil status

Well, I usually don't doubt. If fossil doesn't warn me, I consider it hasn't
thrown away any my local changes. And I don't want to doubt. :)

Regards,
Lluís.

> On Fri, Jan 18, 2013 at 11:37 AM, Lluís Batlle i Rossell
>  wrote:
> > Hello,
> >
> > fossil overwrote some changes I had, without telling, on 'undo' command; I'd
> > prefer it to give a warning.
> >
> > I used:
> > $ fossil merge otherbranch
> > $ test... edit a file... test... and I decide I don't want the merge
> > $ fossil undo   # This restores all files merged, ignoring my file edit.
> >
> > I'd like undo to say "Attention: you have modified this file". What do you 
> > think?
> >
> > Well, I can always "fossil redo", and it'll get back my changes. But a 
> > warning
> > would have been nice.
> >
> > Regards,
> > Lluís.
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Strange fossil use (multiple leaves)

[Lluís Batlle i Rossell]

Hello,

looking at the tcl timeline, I've just seen a checkin like this:
http://core.tcl.tk/tcl/timeline?f=3c4edc83aae0e671

What is that kind of usage? I feel strange that the "merge trunk" has arrows
from *3 trunk leaves*, and *2 more checkins* from one of the trunk branches.

What have they typed to achieve that merge? Why do they have multiple 'trunk'?

I've no idea of how tcl development works, but I'd like to know what fossil
usage pattern they use.

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

[fossil-users] A warning on 'undo'

[Lluís Batlle i Rossell]

Hello,

fossil overwrote some changes I had, without telling, on 'undo' command; I'd
prefer it to give a warning.

I used:
$ fossil merge otherbranch
$ test... edit a file... test... and I decide I don't want the merge
$ fossil undo   # This restores all files merged, ignoring my file edit.

I'd like undo to say "Attention: you have modified this file". What do you 
think?

Well, I can always "fossil redo", and it'll get back my changes. But a warning
would have been nice.

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

[fossil-users] Tags and branches ui

[Lluís Batlle i Rossell]

Hello,

it would be nice if the Tags and Branches ui pages had something more than the
names listed. For example, next to each, could be the date of the head or the
last commit referred to.

What do you think?

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

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

[Lluís Batlle i Rossell]

On Sat, Dec 29, 2012 at 05:37:35PM -0600, Nico Williams wrote:
> On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
>  wrote:
> > On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
> >> And so on.  Really.  Large projects need order, they need process.
> >> They need clean trees in official repos.
> >>
> >> Without a way to clean history prior to pushing to / pulling into
> >> official repos a VCS is just hard to use effectively.
> >
> > I'm not against that; I understand that teams of projects want to organize 
> > what
> > their "VCS history" looks like.
> >
> > What I meant is that (by now) git has only one way of providing such "clean 
> > trees":
> > destroying the history.
> 
> That's a strawman.  I very specifically suggested that a fossil rebase
> operation should *always* copy the branch being rebased and then
> rebase that copy.
> 
> Now what on Earth could possibly be objectionable about that?

Ah sorry, I was only talking about my objections against "git rebase". I don't
know the best way to implement a feature that allows creating 'new history' at
will (not destroying the old).

All I can imagine sounds like a lot of work. :)

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

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

[Lluís Batlle i Rossell]

On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
> On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
>  wrote:
> > (top post, due to the complexity of the previous post)
> >
> > I've found many git-fans that are completely ashamed of how they develop. 
> > And
> > they would never make public how they commit things (how they use the VCS), 
> > so
> > they don't accept other VCS that hasn't git rebasing capabilities.
> 
> And so on.  Really.  Large projects need order, they need process.
> They need clean trees in official repos.
> 
> Without a way to clean history prior to pushing to / pulling into
> official repos a VCS is just hard to use effectively.

I'm not against that; I understand that teams of projects want to organize what
their "VCS history" looks like. 

What I meant is that (by now) git has only one way of providing such "clean 
trees":
destroying the history.

So, for that win (clean the trees at will), there is a forced work pattern: lose
the history. For me the advantadges are less than the disadvantages.

I think both can be achieved, in a VCS. For what I understand, Monotone has
quite nice solutions to that.

One thing is clean *visualisation* (or easy access, whatever), the other is
modifying the raw historical data at the back. Git offers tools to manipulate
the historical data, in order to achieve some visualisation.

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

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

[Lluís Batlle i Rossell]

On Sat, Dec 29, 2012 at 07:55:28PM +0400, Konstantin Khomoutov wrote:
> On Sat, 29 Dec 2012 16:20:32 +0100
> Lluís Batlle i Rossell  wrote:
> You guys do really sound as a religious sect.

:) well, I think that everyone expects different jobs to be done by a VCS.
As for me, I like it to keep history as it happened. Then, fine if it has
methods to reorganize the data in there, but without loosing the original
history.

Some people see the VCS as a tree where they organize the past development in
the way they prefer, not necessarily linked to history.

> 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.

Git people that rewrite history (using rebase), will tell that they reorganize
the commits so they become "more logical". Git does not have a way of doing that
without loosing the history of how all happened.

Of course, git can be used without rebasing. I just haven't met anyone (even me,
who contributes using git in different projects) who doesn't use rebase. And I
use it, because the rest of the team don't want the git graphs "crippled with
_unnecessary_ merges".

> TL;DR

Well, there you go. For some people, writing is easier than reading. ;)

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

Well, I think all this ends up being a matter of taste. Everyone shows their
views. It's like choosing an OS... Some people chose GNU/Linux, despite all the
effort that it requires, because they prefer dealing with fdisk, filesystems,
kernel updates, package managers, ...  than to have the problems of Microsoft
Windows (OS corruption, silent updates, hidden coed, dll hell, crashes, viruses,
etc.). But some people prefer the problems of Windows.  It's a matter of
choosing the problems that annoy you less. :)

And as I mentioned, some people see advantages in having those 'remote' trees
locally, and there are situations where they can be convenient. But for most of
the development I do in a VCS, that's far too heavy.

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

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

[Lluís Batlle i Rossell]

(top post, due to the complexity of the previous post)

I've found many git-fans that are completely ashamed of how they develop. And
they would never make public how they commit things (how they use the VCS), so
they don't accept other VCS that hasn't git rebasing capabilities.

I can't tell what was first: the shame, shameful vcs usage, or the access to
rebase feature.

I dislike how git handles rebase, because by default it does not invite to
rewriting commit logs. If you read git manuals, you are told that each commit
(and its log) refers to a unique *file tree* (represented by the hash), and not
to a *diff*. But then, they wrote 'rebase', which keeps the commit logs, but
changes all the file trees they were meant for.

Then you have commit logs that say "I tested this, and this works". If you
rebase that commit, that looses all that meaning. In fossil, a hash refers to a
specific file tree, that never changes, and checkin comments refer to that hash.

History rewriting also implies that what you could have in your brain memory on 
how you developed something could not match what you have left in the VCS -
after mangling with rebase. I find this also another source of problems.

Regards,
Lluís.

On Sat, Dec 29, 2012 at 02:53:23PM +, Eric wrote:
> On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams  
> wrote:
> 
> 
> Actually I agree with most of Mike Meyer's reply, but I wanted to pick
> this paragraph apart:
> 
> > How many times have you submitted a patch to an upstream
> 
> Well, phrasing it like that says that you are thinking git-style anyway.
> Let's assume a Fossil push with one commit nominated as "this is my
> current contribution".
> 
> > and then been told to make a bunch of changes,
> 
> That's only to be expected, so you create a new commit based on your
> previous nominated one, push it and tell them which is your new commit.
> 
> > re-organize your commits,
> 
> I don't see why they (the centre) should do that. It's the result that
> matters, and if they want a pristine tree that includes only approved
> commits they can do that. (See below.)
> 
> > make specific changes to specific commits,
> 
> Why, why, why? It's the result that matters, this is just rewriting
> _your_ history because they feel like it.
> 
> > and/or squash commits? 
> 
> Again, this is about them wanting a pristine tree. Their problem.
> 
> > Yeah, that's why rebase is good.
> 
> Rebase is a lie!
> Rebase is a lie!
> Rebase is a lie!
> 
> 
> Now for the "pristine tree" thing. I don't agree with it but if that's
> what the project leads want, they can
> 
>   1) not permit pushes or syncs, only pulls, and take only real patches,
>  which they turn into commits themselves
> 
> or
> 
>   2) have two repositories, a working rep which everybody syncs with, and
>  a clean one. Then have a command/script like
> 
>  accept  
> 
>   which creates a new child commit in the clean rep and does a pull back
>   into the working rep, and which is simple in concept, though there
>   will be issues about moves and deletes.
> 
>   Working this way also raises issues about what to do with wiki pages,
>   tickets, and events.
> 
> These approaches are not the outright lie that rebase tends to be,
> but merely the leads saying "here is the history of the things we have
> approved". They are then depriving everyone of the history of blind
> alleys (which will therefore be followed again and again) and of the
> ideas whose time had not yet come (which will therefore have to be
> re-invented from scratch, or may even be forgotten altogether!).
> 
> I think the correct way to deal with "unwanted" commits is to make proper
> use of branches, and perhaps to have a UI option which shows only things
> in a specified set of branches.
> 
> 
> Incidentally, there is nothing stopping you, as a remote, barely-trusted
> developer (which is what you are in that sort of scenario) from running
> the two-repository process yourself, so that you sync only from your
> "clean" repository.
> 
> I also think that much of the "mess" in repositories that people seem to
> want to hide is the result of committing far too frequently, usually in
> the mistaken belief that their VCS is some sort of backup system.
>  
> Eric
> -- 
> ms fnd in a lbry
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil scalability

[Lluís Batlle i Rossell]

On Fri, Dec 21, 2012 at 12:30:25PM +0100, Stefan Bellon wrote:
> Previously I haven't used Fossil for very large repositories. But I
> like its concept and I am thinking about migrating our 15 years of
> history in four parallel Subversion repositories into one Fossil
> repository.
> 
> I wrote a script to replay the commits from Subversion (at the moment
> just "trunk") into Fossil and I am wondering whether I will end up with
> some usable state or not.
> 
> In total, the Subversion repositories hold over 45000 revisions. The
> first 5000 revisions were converted in a quite acceptable time. But
> then things started to slow down. At the moment (at revision 8150) one
> Fossil commit takes around half a minute.

I think you may be interested in the fossil settings "mtime-changes"
and "repo-cksum". Enabling the former, disabling the latter.

By default, a sha1 check of everything is done, per commit.

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

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

[Lluís Batlle i Rossell]

On Wed, Dec 19, 2012 at 12:06:05PM +0100, Remigiusz Modrzejewski wrote:
> 
> On Dec 18, 2012, at 14:42 , Gilles wrote:
> 
> > Out of curiosity, if someone is well-versed with Fossil and the main
> > DVCS systems (Mercurial, Git), I was wondering how Fossil compares to
> > them, for a single user, a small team (up to 20-30), and big teams
> > (thousands).
> > 
> > http://en.wikipedia.org/wiki/List_of_revision_control_software#Distributed_model
> > 
> > Besides the fact that Fossil includes a wiki and a bug tracker, does
> > it offer features that would make it a better solution than the big
> > names?
> 
> Maybe I missed it skimming the thread, but I didn't notice anyone telling 
> about the big point.
> There is an attitude difference between Fossil and the other two, which put 
> in database terms would be:
> Fossil does replication, Git and Mercurial do sharding.
> 
> The big names have been created for huge teams, where people generally don't 
> want to be overwhelmed by tentative work done by others. Therefore they work 
> in isolation, issuing pull requests once the thing is done. Especially in Git 
> it's popular to compress all the commits to be pulled into one big commit. 
> But the important thing is the isolation.
> 
> It stands in stark contrast to Fossil's "everybody has a copy of everything". 
> In almost all the projects I've seen this is realized by another thing that 
> you don't see in the big names: developers autocommit to a central 
> repository. This renders Fossil basically a modern reincarnation of 
> Subversion, what is appealing to a lot of people. As a bonus you get, a 
> little dumbed down, installation of (distributed) Trac for free with every 
> repository.


This is related to having to keep in mind multiple graph HEADs. In fossil,
shared with two computers, you have as important references:
- computer 1:
  - checkout
  - branch head
- computer 2
  - checkout
  - branch head
But any "fossil sync" makes branch heads equal in both computers. So, basically,
3 easy points to take into account.


In git, you have as important references for two computers:
- computer 1
  - index
  - checkout
  - branch head
  - remote computer 2 head
- computer 2
  - index
  - checkout
  - branch head
  - remote computer 1 head

There are many commands to propagate from one ref to the other, but I find it 
very
cumbersome (fetch, pull, push, ...). No 'sync' available' to make things easy.
Not to mention that it needs also special operations to propagate the 'other' 
branches
to the remote places.

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