Re: [fossil-users] Timeline graph problem on fossil-scm.org
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=b37a28228c3788c1fcf026c881eec4017d242dbfunhide 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] Scalability limits
On Fri, Feb 07, 2014 at 07:39:37PM +0100, Gour wrote: On Fri, 7 Feb 2014 18:40:32 +0100 Stephan Beal sgb...@googlemail.com 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
[fossil-users] fossil info does not report leaf/closed
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] fossil info does not report leaf/closed
On Wed, Jan 29, 2014 at 03:54:22PM +0100, Stephan Beal wrote: On Wed, Jan 29, 2014 at 3:52 PM, Stephan Beal sgb...@googlemail.com 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
Re: [fossil-users] fossil info does not report leaf/closed
On Wed, Jan 29, 2014 at 04:17:38PM +0100, Stephan Beal wrote: On Wed, Jan 29, 2014 at 4:13 PM, Stephan Beal sgb...@googlemail.com 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
[fossil-users] Get a checkin diff from cli
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] Get a checkin diff from cli
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 vi...@viric.namewrote: 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] 1.28 vdiff changes
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] 1.28 vdiff changes
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
Re: [fossil-users] Version 1.28 release?
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?
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?
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
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
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...
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 d...@sqlite.org 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
On Tue, Jul 30, 2013 at 10:11:52AM +0100, Jan Nijtmans wrote: 2013/7/12 Stephan Beal sgb...@googlemail.com: 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: http://www.fossil-scm.org/index.html/info/2015bbd55d 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 10:45:31AM +0100, Jan Nijtmans wrote: 2013/7/30 Lluís Batlle i Rossell vi...@viric.name: 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] Fossil on cygwin64
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 d...@sqlite.org: 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
On Thu, Jul 25, 2013 at 07:59:38AM -0400, Richard Hipp wrote: On Thu, Jul 25, 2013 at 7:44 AM, Martin Gagnon eme...@gmail.com 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
On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote: 2013/7/25 Richard Hipp d...@sqlite.org: 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
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 eme...@gmail.com:
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
Re: [fossil-users] Fossil on cygwin64
On Wed, Jul 24, 2013 at 11:16:19AM +0200, Jan Nijtmans wrote: 2013/7/24 Lluís Batlle i Rossell vi...@viric.name: 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
On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote: 2013/7/24 Lluís Batlle i Rossell vi...@viric.name: 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
On Wed, Jul 24, 2013 at 11:53:02AM +0200, Jan Nijtmans wrote: 2013/7/24 Lluís Batlle i Rossell vi...@viric.name: 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
[fossil-users] Fossil on cygwin64
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
[fossil-users] autosync with fossil merge
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] autosync with fossil merge
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 vi...@viric.namewrote: 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
Re: [fossil-users] autosync with fossil merge
On Fri, Jul 19, 2013 at 07:26:57PM +0200, Stephan Beal wrote: On Fri, Jul 19, 2013 at 7:00 PM, sky5w...@gmail.com 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] Side-by-side diff improvement
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
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=98aec3c55155011bv2=d74d0c320c455abdsbs=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=6a58f2dd9ada9a81to=8b0984ab46648f58sbs=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
On Mon, Jun 17, 2013 at 10:56:03AM -0400, Richard Hipp wrote: On Mon, Jun 17, 2013 at 10:48 AM, Brandon Invergo bran...@invergo.netwrote: 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...
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
On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote: On Mon, May 13, 2013 at 10:41 AM, Andy Bradford amb-fos...@bradfords.orgwrote: 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
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 vi...@viric.namewrote: 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
Re: [fossil-users] Wiki-Pages synchronisation
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 vi...@viric.namewrote: 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] TH1 bomb
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] Ticket 'subsystem' field?
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
Hello, the links to the attachments added are broken in the timeline. Example: http://fossil-scm.org/index.html/timeline?u=stephanc=2013-01-25+17%3A41%3A18ndn=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
Re: [fossil-users] Good repository to test scalability of fossil
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
[fossil-users] bisect 'test failed'
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] bisect 'test failed'
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 vi...@viric.namewrote: 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
Re: [fossil-users] bisect 'test failed'
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 vi...@viric.namewrote: 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'
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 vi...@viric.namewrote: 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
[fossil-users] The finfo page, and the graph there
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
Re: [fossil-users] The finfo page, and the graph there
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 vi...@viric.namewrote: 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.cfco=1 (2) http://www.fossil-scm.org/fossil/finfo?fco=0name=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
Re: [fossil-users] Odd problem syncing to fossil repo
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 r...@ronware.org mailto:r...@ronware.org 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
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=ee33b951a4063e33filename=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] The checkin comment in the info page
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 'verbatim', ... 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
[fossil-users] Bad error in case of db locked
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
Re: [fossil-users] Making the go tool support fossil
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
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 vi...@viric.name wrote: [...] That's correct, but Lluis is right in suggesting that we should have a command like: fossil ping repo-address which can piggyback on the protocols supported by cloning (ssh/http [s]), but: a) does no authentication checks (because we cannot know which permissions would be required by later commands). b) does no useful work - simply checks for connectivity. c) returns a trivial response, e.g. OK or FAIL, and uses the exit code to report success/failure. Well it would be better if it reported something like 'fossil info' for tip. :) This might contradict point (a) above in certain setups, does it? I mean that my own repos require authentication only for pushing but supposedly there might be some use for locked down private repos. I just don't know is it possible to fully lock a Fossil repo so that any access to it must be authenticated. 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 09:40:27AM -0500, Richard Hipp wrote: On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom car...@wistly.net wrote: Stephan Beal sgb...@googlemail.com 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
Re: [fossil-users] Change the CSS
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] Change the CSS
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 vi...@viric.namewrote: 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
[fossil-users] Making the go tool support fossil
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] Making the go tool support fossil
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 vi...@viric.namewrote: 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
Re: [fossil-users] Making the go tool support fossil
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
vi...@viric.namewrote:
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
[fossil-users] Password asked per push
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
[fossil-users] Change the CSS
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
[fossil-users] Ticket changes and mimetype
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] Ticket changes and mimetype
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
Re: [fossil-users] Ticket changes and mimetype
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
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 vi...@viric.namewrote: 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
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 vi...@viric.namewrote: 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 vi...@viric.namewrote: 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
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 vi...@viric.namewrote: 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
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 vi...@viric.namewrote: 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
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] cannot find a common ancestor between the current checkout
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
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
On Tue, Jan 29, 2013 at 08:59:19AM +0100, Gilles wrote: On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland estifo...@gmail.com 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
On Mon, Jan 28, 2013 at 10:21:03AM +0100, Gilles wrote: On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp d...@sqlite.org wrote: On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell vi...@viric.namewrote: 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] howto `grep' through old revisions
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 vi...@viric.name 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] Strange fossil use (multiple leaves)
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 vi...@viric.name 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
[fossil-users] A warning on 'undo'
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] Strange fossil use (multiple leaves)
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
Re: [fossil-users] A warning on 'undo'
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 vi...@viric.name 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] Tags and branches ui
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.?
(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 n...@cryptonector.com wrote: snip 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 commit-in-working-rep parent-in-clean-rep 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 vs. Git/Mercurial/etc.?
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 vi...@viric.name wrote: sarcasmYou guys do really sound as a religious sect./sarcasm :) 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.?
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 vi...@viric.name 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.?
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 vi...@viric.name 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.?
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
Re: [fossil-users] Improvements to side-by-side diff
On Mon, Dec 17, 2012 at 10:27:09AM +0100, Paolo Bolzoni wrote: Maybe joining both ideas? Like coloring the whole word of a more neutral color and the difference with the usual bright color? I think it would be the best as I agree with both point of views. Fwiw, I'd prefer only the per-character differences to be highlighted. I quite like what 'meld' does, and that's what I'd like fossil to look like. :) Regards, Lluís. On Mon, Dec 17, 2012 at 10:03 AM, Martijn Coppoolse li...@martijn.coppoolse.com wrote: On 17-12-2012 8:33, Baruch Burstein wrote: Another suggestion: Since visual diffs are always for text files (I think), it doesn't make much sense to mark partial words as changed. If the whole word is not unchanged, then the whole word is changed. I am referring to things like line 73817 on the left in the fourth link below. Respectfully disagree. The line you refer to works perfectly fine; I see no reason to reduce granularity to word level, and every reason to keep it the way it works now: if a word is partially changed, I like to see _what_ part was changed. IMO, diff highlighting should highlight changes, not words. I can recognize words by myself just fine; seeing what exactly changed is what I need the highlighting for. Also, in my case (at least), visual diffs are usually for text files representing source code. In code, especially for a case-sensitive language, a change to a single character can be crucial. Reducing highlighting to only indicate changes per word makes it more difficult to see this. On Sat, Dec 15, 2012 at 4:16 AM, Richard Hipp d...@sqlite.org mailto:d...@sqlite.org wrote: Reposted from fossil-dev: OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 OLD: http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 NEW: http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎɟı ˙pɐǝɥ ʎɯ uo buıʇʇıs uǝɥʍ ǝuıɟ ʇsnظ uʍop ǝpısdn pɐǝɹ uɐɔ ı ¡ʎןןıs ǝq ʇ’uop -- Martijn Coppoolse ___ 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] Fossil vs. Git/Mercurial/etc.?
On Tue, Dec 18, 2012 at 03:29:19PM -0600, Mike Meyer wrote: On Tue, 18 Dec 2012 14:42:34 +0100 Gilles gilles.gana...@free.fr wrote: Out of curiosity, if someone is well-versed with Fossil and the main DVCS systems (Mercurial, Git), Fossil: it's strong points are the built-in wiki and ticket tracking system, and that it's a single self-contained binary. What sets it apart as a DSCM is autosync mode and that you can have multiple work spaces checked out of the same repository. Monotone also works as a self-contained binary (written in C++, with more library dependencies, but all can be statically linked if desired). And it has a centralised database, from where you can have multiple checkouts and multiple repositories. And it has a very powerful tagging mechanism. 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] High cpu usage, ci_edit adding tag
Hello, adding a tag, in the edit checking page, it takes 15s of server cpu time (a reasonably fast Atom x86_64) for our repository. Repository statistics: Repository Size:274292736 bytes (274.3MB) Number Of Artifacts:31867 (stored as 12262 full text and 19605 delta blobs) Uncompressed Artifact Size: 29821 bytes average, 36923728 bytes max, 950291231 bytes (950.3MB) total What is it doing, in 15s? 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] High cpu usage, ci_edit adding tag
On Mon, Dec 17, 2012 at 08:28:22AM -0500, Richard Hipp wrote: On Mon, Dec 17, 2012 at 4:07 AM, Lluís Batlle i Rossell vi...@viric.namewrote: Hello, adding a tag, in the edit checking page, it takes 15s of server cpu time (a reasonably fast Atom x86_64) for our repository. Repository statistics: Repository Size:274292736 bytes (274.3MB) Number Of Artifacts:31867 (stored as 12262 full text and 19605 delta blobs) Uncompressed Artifact Size: 29821 bytes average, 36923728 bytes max, 950291231 bytes (950.3MB) total What is it doing, in 15s? Propagating the consequences of that tag change to thousands of check-ins maybe? What was the tag? And to which node of your DAG did you add it? The 3rd checkin, counting from most recent. And it was not a propagating tag. ___ fossil-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
On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote: On Sat, 24 Nov 2012 13:57:41 +0100, j. v. d. hoff veedeeh...@googlemail.com wrote: question: is there a straightforward (or sqlite-based) way to `grep' through a specified file recursively backward in time through all revisions (or until first hit of the search pattern)? 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? I'm looking for a function that I know is a file somewhere, but don't know how to proceed. As I said early in the thread, deconstruct + grep. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to change number of columns for a side-by-side diff in the web interface
On Tue, Dec 04, 2012 at 03:27:37PM -0200, Jonas Malaco Filho wrote: First, is there an option to change the number of columns for side-by-side diffs on the web interface? Also, is there any setting to change the default number of columns for SBS diffs, or could one be included? *Jonas Malaco Filho* iirc, you can add the GET form parameter 'dc'. dc=90 for example. Add the proper or ? separators. I still keep the branch of the fossil we use, 'annotate_links', displaying *all* columns of each file, in the default SBS show. We use SBS for reviewing, and once we had neglected a change that was over the 80th column, and went on trunk. Since then, we consider it a risk to have a trimmed diff. 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] How to change number of columns for a side-by-side diff in the web interface
On Tue, Dec 04, 2012 at 03:42:46PM -0200, Jonas Malaco Filho wrote: Shouldn't it be dw=90? Ah right. dc is for the number of context lines. Also, how did you change the default SBS show? The source code of the diff is different in trunk and in my branch. 2012/12/4 Lluís Batlle i Rossell vi...@viric.name I still keep the branch of the fossil we use, 'annotate_links', displaying *all* columns of each file, in the default SBS show. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil as DLL?
On Mon, Nov 26, 2012 at 01:52:53PM -0600, Nico Williams wrote: IIUC the main reason to want a DLL instead of having to spawn a new process for every operation is iOS. I hear that the dearth of excellent git (and other) SCM clients for iOS has to do with the constrained nature of the run-time environment. fossil uses fork() quite enough, and its memory management depends on that, for what I understand. ___ fossil-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
On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote: On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: question: is there a straightforward (or sqlite-based) way to `grep' through a specified file recursively backward in time through all revisions (or until first hit of the search pattern)? j. ps: yes, I would know now (after having learned how to use `fossil artifact' correctly...) how to write a shell script doing that. but that would mean to dump the full content of each revision and pipe it through the grep which will become slow if there are too many revisions. so the question is whether the functionality is already builtin (possibly grepping through the deltas instead). This functionality is not built-in. Nobody has ever thought of it before in 6 years of use, apparently, or at least has not mentioned it to me. I use this from time to time. My procedure goes through deconstructing the database, grepping recursive, and resolving back the hashes with fossil 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] howto `grep' through old revisions
On Sat, Nov 24, 2012 at 08:59:58AM -0500, Richard Hipp wrote: On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote: On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: question: is there a straightforward (or sqlite-based) way to `grep' through a specified file recursively backward in time through all revisions (or until first hit of the search pattern)? j. ps: yes, I would know now (after having learned how to use `fossil artifact' correctly...) how to write a shell script doing that. but that would mean to dump the full content of each revision and pipe it through the grep which will become slow if there are too many revisions. so the question is whether the functionality is already builtin (possibly grepping through the deltas instead). This functionality is not built-in. Nobody has ever thought of it before in 6 years of use, apparently, or at least has not mentioned it to me. I use this from time to time. My procedure goes through deconstructing the database, grepping recursive, and resolving back the hashes with fossil ui. So what should the output look like? Suppose we implement a command: fossil grep REGEXP FILENAMEGLOB Which searches all historical versions of files that match FILENAMEGLOB for patterns that match REGEXP. Suppose for concreteness that the regular expression is xyzzy and the file is ex1.txt. If there are 1000 different revisions of ex1.txt, does it search them all looking for xyzzy and show each hit? Or did it stop going backwards in time at the first hit it find? I don't really know much, what I'd want. When I've used deconstruct, sometimes I wanted to grep files, sometimes tickets, sometimes checkin comments, sometimes in-file comments... I guess that 'grep' for only files, and some kind of FTS for the rest would be very nice. We use tickets extensively for bug tracking, but bugfixes happen as checkins, and sometimes we hit oh, I seem to remind that we had a case similar to this. And then I've to grep all to try to find out, even with different keywords, because who knows where I had that stored. But as after having the results, I end up wanting to check all results with the UI, I guess a ui option with links would be nicer. 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] serious problem with wiki editing
On Tue, Nov 20, 2012 at 06:20:02AM +, K wrote: This is as a result of a featured added on my behalf, I'm afraid. There should now be (I haven't found occasion to update my Fossil to 1.24 given I'd have to repatch the wiki page name length requirement) an option somewhere allowing the treatment of [xxx] as wiki mark up. Sorry, what is this new feature about, and its consequences? And the motivation of the change? I might have missed the rationale. Regards, Lluís. on Nov 19, 2012, Ron Aaron r...@ronware.org wrote: When I add a link [whatever] in my wiki page, as of fossil b058c8a944 I no longer see the link, but only get the literal text entered! The repo is set for the default settings, no WYSIWG or HTML ___ 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] serious problem with wiki editing
On Tue, Nov 20, 2012 at 07:28:30AM -0500, Richard Hipp wrote: On Tue, Nov 20, 2012 at 4:32 AM, Lluís Batlle i Rossell vi...@viric.namewrote: On Tue, Nov 20, 2012 at 06:20:02AM +, K wrote: This is as a result of a featured added on my behalf, I'm afraid. There should now be (I haven't found occasion to update my Fossil to 1.24 given I'd have to repatch the wiki page name length requirement) an option somewhere allowing the treatment of [xxx] as wiki mark up. Sorry, what is this new feature about, and its consequences? And the motivation of the change? I might have missed the rationale. Please tell me why you think this is not a good idea? If necessary, it can be made optional. But I couldn't think of a reason to display broken links in red rather than just not transforming them at all. Thank you for the explanation; now that I know the intended behaviour, it looks fine to me. No objection. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Search tickets
Hello, if I understand correctly, the Tickets system lacks a 'Ticket Search page'. It allows to create Ticket Reports, but I think it would be nice if it allowed also to create 'Ticket Search pages'. That'd look like html+th1 (like New Ticket), but the result operation would be a sql query, and would be available as a list of pages next to ticket reports. Every user could create their search pages, like reports. We use tickets a lot, and have lots of them, and we don't find the creation of multiple reports easy enough to handle. What do you think? Any volunteer? 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] Help improve bot exclusion
On Tue, Oct 30, 2012 at 06:17:05AM -0400, Richard Hipp wrote: Finally: Do you have any further ideas on how to defend a Fossil website against runs such as the two we observed on SQLite last night? This problem affects almost any web software, and I think that job is delegated to robots.txt. Isn't this approach good enough? And in the particular case of the fossil standalone server, it could serve a robots.txt. How do programs like 'viewcvs' or 'viewsvn' deal with 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] Questions about fossil
On Sun, Oct 21, 2012 at 01:29:56PM +0200, Paolo Bolzoni wrote: I love fossil and use it in all my projects, and using I got few questions I cannot find the answers... - Can I change the zip archive name in the check-in page? The zip file name is the last part of the url, in /zip/anything-UUID.zip. - Can I change the directory name inside the zip archive? The directory name is the ?name=xxx of the zip archive url. - It is possible to change a typo in a commit message in autosync mode? (without dumping the fossil database, changing the dump, remaking it) Yes sure; go to the checkin edit page, and change it. That will generate a new ticket with the commit message change, and all sync-ed fossil will show the updated checkin message for that checkin. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Handling merge conflicts?
On Sun, Oct 21, 2012 at 02:54:06PM -0400, Richard Hipp wrote: In the change above, there is no explicit resolve step. Fossil automatically senses whether or not you have resolved the conflict through editing. I think that the change misses one of the most valuable situations - those of binary files conflict, where comitting directly after merge would destroy any evidence of conflict. I got that by a quick glance at the patch though; I may have missed something. Regards, Lluís. You can get rid of those extra files with the new --temp option to the fossil clean command: fossil clean --temp That's a nice option! :) 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] add/commit file through web interface
On Wed, Oct 17, 2012 at 10:44:37AM -0400, Ron Wilson wrote: I'm sorry. It is burried in there. We were looking for it on the New Ticket page. Weird that all 6 of us would miss that. We use the ticket attachments quite a lot. It works fine here, and it's enough for our needs. On 10/16/12, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 16, 2012 at 7:43 PM, Ron Wilson ronw.m...@gmail.com wrote: How much would it take to enabled add+commit a file via the web interface? Specifically, as a means to attach files to tickets. We have unsophistocated users who are asking for the ability to submit tickets themselves rather than rely on us in SW development to enter tickets on their behalf. This makes sense because we almost always have to ask for more information, The problem these users have is including supporting files, like diagrams, photographs, log files, etc, with tickets. With in our team, we can easily add and commit files is a reserved directory, then paste in links in the tickets. These other users have much difficulty doing that. There is an Attachment mechanism that works for Wiki pages. I thought I had that going for Tickets too, though perhaps I never got around to that. (I haven't had that itch yet.) Giving users the ability to add attachments to tickets seems like a better approach, since it avoids cluttering the source code with attachment files. ___ 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
Re: [fossil-users] Downloading raw artifacts
On Mon, Aug 13, 2012 at 06:30:56PM +0200, Lluís Batlle i Rossell wrote: On Mon, Aug 13, 2012 at 12:19:28PM -0400, Richard Hipp wrote: An artifact does not necessarily have a filename, or it might have multiple filenames. Nevertheless, we can guess at the filename, and from that guess at the mimetype. http://www.fossil-scm.org/fossil/info/af16836c23 Thank you! I'll test it. I thought you would change the link to the Raw download: http://www.fossil-scm.org/fossil/artifact/33360c8c6055dfacfd6c6e7a98b0fc4bc42d6e59?ln=1446 to include m=blabla, as done a bit below, http://www.fossil-scm.org/fossil/artifact/33360c8c6055dfacfd6c6e7a98b0fc4bc42d6e59?ln=1492 Will your change work for an artifact that comes as a wiki page attachment? (that was my original case). I wrote a code change that makes this work for the attachments: http://fossil-scm.org/index.html/info/5f3916ac5b 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
