Re: [fossil-users] fossil cut first charracter of the filename
Hello, Perhaps the error is a bit misleading... Should it be possible to add files that are above the root of the open fossil repository? This would be a nice feature to have. I want to use fossil to manage changes on linux based VPN Routers. Some of my config files live in /etc , some in /opt/scripts. It would be nice to be possible to run fossil from something like /opt/archive. Currently, for my purposes, I can only run it from (/) root directory which is not so flexible. Andrey Shtine ___ fossil-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 cut first charracter of the filename
Hello, On 9 January 2014 09:43, shtine sht...@runway.lv wrote: Hello, Perhaps the error is a bit misleading... Should it be possible to add files that are above the root of the open fossil repository? This would be a nice feature to have. I want to use fossil to manage changes on linux based VPN Routers. Some of my config files live in /etc , some in /opt/scripts. It would be nice to be possible to run fossil from something like /opt/archive. Currently, for my purposes, I can only run it from (/) root directory which is not so flexible. Perhaps having fossil manage files outside its own root is not practical to implement/want, I don't know. BTW, I use something very similar to what you have there: all config/source/binaries that make a vanilla system into a system so-and-so usable for me live in /cust. Inside that dir is a dir 'linkroot' which acts like an overlay to the root-dir. (There's a /cust/linkroot/etc/rc.local, for instance.) Also in /cust is an 'install' script, which does basically the following: traverse /cust/linkroot, and for each file/dir there, set up a symlink in the normal filesystem, pointing to somewhere within 'linkroot'. Care is taken that already existing files/dirs are renamed out of the way, and some other shortcuts. The /cust is the root of the fossil-repo for that (type of) machine. It works very well; I can effectively 'clone' a machine by opening the repo and running the 'install'-script. And of course the versioning, history and possible protection against fsckups is great :-) If interested I can share the install-script; it's not rocket science, comes with no guarantees and is only tested on NetBSD. But may be used as a starting point. Michai Andrey Shtine ___ 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] Using Markdown for tickets and in TH1
All, Attached a patch which will do several things: 1) Add a [markdown ] TH1 command to allow access to the included markdown parser from TH1 2) Slightly tweaked the markdown parser to not produce a p/p pair for strings with at most one newline 3) Changed the default ticket page templates to provide Markdown input using the already defined text/x-markdown mimetype Only thing left to be done is to extend the markdown parser so that [uuid] will refer to the fossil artifact as in the fossil wiki parser. Regards, Mark markdown-tickets.patch Description: Binary data ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil cut first charracter of the filename
On Thu, Jan 09, 2014 at 10:45:35AM +0100, Michai Ramakers wrote: Hello, On 9 January 2014 09:43, shtine sht...@runway.lv wrote: Hello, Perhaps the error is a bit misleading... Should it be possible to add files that are above the root of the open fossil repository? This would be a nice feature to have. I want to use fossil to manage changes on linux based VPN Routers. Some of my config files live in /etc , some in /opt/scripts. It would be nice to be possible to run fossil from something like /opt/archive. Currently, for my purposes, I can only run it from (/) root directory which is not so flexible. Perhaps having fossil manage files outside its own root is not practical to implement/want, I don't know. And can be very confusing and dangerous. Imagine working from /a/b/c/d/e/f/g/checkoutdir and adding file ../../../../../file.txt. Later, one open a checkout in /a/b. Where file.txt will go ? Or the file could also goes inside another checkout, a clean in this other checkout could delete latest change. [snip] Actually, latest version of trunk work for a checkout on '/', which was not the case before. It is less flexible for you to work on '/' but could be use. In my case I don't do that on my workstation but on some headless BSD server where I want to track changes on system configuration files. -- 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] Small issue with ticket hook script
When I use the following script as a ticket hook:
set project simpletask
tclInvoke package require http
query {SELECT title, status
FROM ticket
WHERE tkt_uuid=$uuid} {
set title [tclInvoke http::formatQuery $title]
http -asynchronous --
http://127.0.0.1/cgi-bin/tkt-hook?uuid=$uuidtitle=$titlestatus=$statusproject=$project
}
The reflected information in the query is the info from before the ticket
update.
I suspect the ticket hook is fired before the actual ticket change
transaction is commited. Would it be possible to reverse this so that the
hook script will be executed after the ticket change has been commited?
Thanks,
Mark
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
2014/1/9 Mark Janssen mpc.jans...@gmail.com: The reflected information in the query is the info from before the ticket update. I suspect the ticket hook is fired before the actual ticket change transaction is commited. Would it be possible to reverse this so that the hook script will be executed after the ticket change has been commited? I'll have a look at that. In your test, how did the ticket change come in? Either with an xfer from another repository, or simply edited in the web-interface. This difference is important: The code path leading to the hook firing is different in those two situations. Thanks! 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] Version 1.28 release?
It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? -- 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
Re: [fossil-users] Small issue with ticket hook script
On Thu, Jan 9, 2014 at 2:20 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
2014/1/9 Mark Janssen mpc.jans...@gmail.com:
The reflected information in the query is the info from before the ticket
update.
I suspect the ticket hook is fired before the actual ticket change
transaction is commited. Would it be possible to reverse this so that the
hook script will be executed after the ticket change has been commited?
I'll have a look at that. In your test, how did the ticket change come in?
Either with an xfer from another repository, or simply edited in the
web-interface. This difference is important: The code path leading
to the hook firing is different in those two situations.
Thanks!
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I tested it with ticket changes from the web interface. Patch below fixes
the behavior for the webinterface, Not sure about tickets that are
transfered in.
Mark
Index: src/manifest.c
==
--- src/manifest.c
+++ src/manifest.c
@@ -1882,19 +1882,20 @@
);
}
}
if( p-type==CFTYPE_TICKET ){
char *zTag;
-
+manifest_crosslink_begin();
zScript = xfer_ticket_code();
zUuid = p-zTicketUuid;
assert( manifest_crosslink_busy==1 );
zTag = mprintf(tkt-%s, p-zTicketUuid);
tag_insert(zTag, 1, 0, rid, p-rDate, rid);
free(zTag);
db_multi_exec(INSERT OR IGNORE INTO pending_tkt VALUES(%Q),
p-zTicketUuid);
+manifest_crosslink_end();
}
if( p-type==CFTYPE_ATTACHMENT ){
db_multi_exec(
INSERT INTO attachment(attachid, mtime, src, target,
filename, comment, user)
Index: src/tkt.c
==
--- src/tkt.c
+++ src/tkt.c
@@ -534,14 +534,12 @@
);
}else{
db_multi_exec(INSERT OR IGNORE INTO unsent VALUES(%d);, rid);
db_multi_exec(INSERT OR IGNORE INTO unclustered VALUES(%d);, rid);
}
- manifest_crosslink_begin();
result = (manifest_crosslink(rid, pTicket, MC_PERMIT_HOOKS)==0);
assert( blob_is_reset(pTicket) );
- manifest_crosslink_end();
return result;
}
/*
** Subscript command: submit_ticket
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
2014/1/9 Mark Janssen mpc.jans...@gmail.com: I tested it with ticket changes from the web interface. That's indeed what I suspected. I have a different fix in mind, I'll come back on that later. Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 9, 2014 at 8:54 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/9 Richard Hipp d...@sqlite.org: It has been a few months since the last official release of Fossil. I wonder if we should consider publishing trunk as the official version 1.28? That's fine with me! I think Fossil's trunk is quite stable now. One thing to consider would be which SQLite amalgamation should be included in it. One way to make both developers and package maintainers happy (as being discussed in Fossil-Users mailing list) could be: 1) Create a branch-1.28 from fossil trunk now (or any other suitable moment in the future). 2) Create a SQLite amalgamation from here: http://www.sqlite.org/src/timeline?r=branch-3.8.2 and replace Fossil's sqlite3.c and sqlite3.h in Fossil's branch-1.28 branch. I view Fossil as supporting SQLite, not the other way around. (Remember, that's why Fossil was original written!) As part of its role of supporting SQLite, Fossil serves as a test platform for the latest SQLite alphas. For that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not the most recent release. Then trunk can be continued to be developed with the latest-and-greatest SQLite version, while Fossil 1.28 will be release with the best-tested-and-most-stable SQLite version. Of course, more bug-fixes could be merged to SQLite's branch-3.8.2 branch, but I don't see any which are relevant to Fossil. 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 -- 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
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: I view Fossil as supporting SQLite, not the other way around. (Remember, that's why Fossil was original written!) As part of its role of supporting SQLite, Fossil serves as a test platform for the latest SQLite alphas. For that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not the most recent release. I already expected that answer, and it's perfectly fine. As developer I completely agree with that. But package maintainers prefer to release Fossil with the most stable SQLite, they don't want to play the role as SQLite testers. As (Cygwin) package maintainer (for SQLite, not for Fossil) I completely agree with that. There are two ways package maintainers can get what they want: - Replace Fossil's SQLite amagalmation with whatever they want, probably SQLite 3.8.2 (maybe with backported bugfixes) - Compile Fossil with --disable-internal-sqlite. In both situations, the package maintainers are responsible for whatever bug this introduces in Fossil. The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. I hope this is an important argument for keeping the --disable-internal-sqlite option. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. 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. -- 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
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 09, 2014 at 09:31:59AM -0500, Richard Hipp wrote: On Thu, Jan 9, 2014 at 9:17 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: The latter has the advantage that no new Fossil binary has to be built when SQLite 3.8.3 is released. Fossil will always follow the latest stable SQLite automatically. 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. Regards, -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Confirm commit
Hello, When developing, I often execute last command blindly and sometimes it happens to be `fossil ci -m text`. And sometimes I commit, forgetting that I'm on a wrong branch. So I purpose to add commit confirmation that contains number of changes and a branch name. One might say, just be careful. I say — less distraction. -- Best regards, Arseniy Terekhin ___ fossil-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 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. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: 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. SQLite alphas are more robust that stables of most other software projects. -- 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
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] Version 1.28 release?
On Jan 9, 2014, at 16:14 , Richard Hipp wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: 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. SQLite alphas are more robust that stables of most other software projects. Good point. However, this is one that can be hard to explain to distributors. It would be a shame to see new Fossil releases not adopted due to that. Disclaimer: I have no idea if this would be the case. Personally, knowing SQLite testing, I have nothing against using current version in my system. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Confirm commit
On Thu, Jan 9, 2014 at 3:54 PM, Arseniy Terekhin sen...@gmail.com wrote: Hello, When developing, I often execute last command blindly and sometimes it happens to be `fossil ci -m text`. And sometimes I commit, forgetting that I'm on a wrong branch. So I purpose to add commit confirmation that contains number of changes and a branch name. One might say, just be careful. I say — less distraction. -- Best regards, Arseniy Terekhin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users Don't use -m and the editor popup for the commit message will be your reminder. ___ fossil-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 9, 2014 at 6:14 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.pl 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. SQLite alphas are more robust that stables of most other software projects. I'd be more concerned about the appearance of using a SQLite alpha in Fossil. People have to have a great deal of faith in the quality and stability of their VCS - using anything branded alpha even on the insistence that it's better than most other stables could have a damaging effect on Fossil's reputation. ___ fossil-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?
Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. Fossil is a critical application that deserves its own shelf. Thanks for Fossil and SQLite! On Thu, Jan 9, 2014 at 10:21 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 9, 2014, at 16:14 , Richard Hipp wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: 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. SQLite alphas are more robust that stables of most other software projects. Good point. However, this is one that can be hard to explain to distributors. It would be a shame to see new Fossil releases not adopted due to that. Disclaimer: I have no idea if this would be the case. Personally, knowing SQLite testing, I have nothing against using current version in my system. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, 09 Jan 2014 16:26:35 +0100, Ramey, Christopher cra...@extraarms.com wrote: On Thu, Jan 9, 2014 at 6:14 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 10:12 AM, Remigiusz Modrzejewski l...@maxnet.org.pl 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. SQLite alphas are more robust that stables of most other software projects. I'd be more concerned about the appearance of using a SQLite alpha in Fossil. People have to have a great deal of faith in the quality and stability of their VCS - using anything branded alpha even on the insistence that it's better than most other stables could have a damaging effect on Fossil's reputation. +1 were I not already using fossil in the first please, reading that the considered DVCS uses alpha state software for it's database (of all things...) would quite probably put me off immediately. we are talking about a revision control system, not a chat client (or what else). and I really do believe fossil deserves to gain more following in the DVCS wars which aim might be harmed by the proposed approach. personally, I can trust your statement (that the alphas are robust (although a contradiction in terms)) and, therefore, do have no problem in using fossil this way. for newcomers the reaction very very probably will be different. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-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?
A consensus seems to be emerging that perception is more important that truth and hence the latest release of SQLite should be in the Fossil release, rather than the latest trunk version of SQLite. I think that is silly, but I will yield to the consensus. Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? I'll continue to keep the latest SQLite trunk on the Fossil trunk, and run the Fossil trunk on important websites like http://www.sqlite.org/, http://www.fossil-scm.org/, and http://core.tcl.tk/. That will be sufficient testing. -- 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
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? http://fossil-scm.org/index.html/timeline?r=branch-1.28 Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Thu, 09 Jan 2014 16:55:17 +0100, Richard Hipp d...@sqlite.org wrote: A consensus seems to be emerging that perception is more important that truth and hence the latest release of SQLite should be in the Fossil more important than truth? I think nobody said so and I would not agree to that consensus. the question rather seems whether you care for adoption of `fossil' -- in which case, indeed, perception of the potential new users is a non-negligible factor. personally, I would like to see an increase of the user base and broader acceptance of fossil, especially since `git' (with its tons of gotchas making it ill fit for human-sized projects in my view) increasingly seems to be the only (recognized) game in town. release, rather than the latest trunk version of SQLite. I think that is silly, but I will yield to the consensus. Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? I'll continue to keep the latest SQLite trunk on the Fossil trunk, and run the Fossil trunk on important websites like http://www.sqlite.org/, http://www.fossil-scm.org/, and http://core.tcl.tk/. That will be sufficient testing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-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 9, 2014 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/9 Richard Hipp d...@sqlite.org: Jan - would you like to start the branch-1.28 containing the SQLite 3.8.2 release? http://fossil-scm.org/index.html/timeline?r=branch-1.28 Jan: tnx Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. -- 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
Re: [fossil-users] Version 1.28 release?
2014/1/9 Richard Hipp d...@sqlite.org: Jan: tnx Your're welcome! Everybody: Please download, compile, and test the branch above. If there are no issues reported, it will become the official 1.28 release. I compiled/ran it on Cygwin64, and make test ended with: * Final result: 2 errors out of 18914 tests * Failures: merge-utf-24-23 merge-utf-24-32 This is no big deal: Fossil 1.26 and 1.27 had the same failures, I am convinced that those 2 are test-case errors. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com: I have a different fix in mind, I'll come back on that later. http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook Does this work for you? Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
On Jan 9, 2014, at 16:35 , sky5w...@gmail.com wrote: Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. SQLite QA is so impressive that some may be pretty comfortable with having any version, provided it has passed a full test suite, included in their systems. The problem here is the message sent by the word alpha. What it usually means is I just wrote it, hope it will not explode in your face, but no warranties. Therefore if we want to say Fossil is rock-solid, we can't say it uses alpha libs, just to avoid the confusion, no matter the actual quality. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com: I have a different fix in mind, I'll come back on that later. http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook Does this work for you? 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 No with this a ticket change from the web UI will not trigger the xfer script. ___ fossil-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: set v 0; unset v; info exists v;
On Sun, 5 Jan 2014, Joe Mistachkin wrote:
Sergei Gavrikov wrote:
It seems this was introduced with Th_ExistsVar()
http://fossil-scm.org/index.html/artifact/a561c58c237b3eb43eaf55e6f9cc6a9b8a
26e5d1?ln=1154-1159
(check-in http://fossil-scm.org/index.html/info/4f8c8975bc). As I could
see Th_ExistsVar() does miss a test for pValue-zData as Th_GetVar() does
http://fossil-scm.org/index.html/artifact/a561c58c237b3eb43eaf55e6f9cc6a9b8a
26e5d1?ln=1142-1149.
Right? Could you, please, fix that?
Sergei Gavrikov also wrote:
Th_UnsetVar() creates (creatok=1), then unset variable. So, unset never
raise an error. It is okay?
Thanks for the report(s). Fixed here:
https://www.fossil-scm.org/index.html/info/7164f52baa
And here:
https://www.fossil-scm.org/index.html/info/99bdfa0b95
Thank you for the fixes! I'm sorry, but, I found yet another issue with
Th_ExistsVar(). If a variable is not exists, Th_ExistsVar() does clear
TH stack trace:
# Expect {foo}, but get nothing {}.
catch foo; info exists bar; set ::th_stack_trace
Call path: Th_ExistsVar() - thFindValue() - Th_ErrorMessage() - ...
Th_SetVar(interp, (char *)::th_stack_trace, -1, 0, 0);
Unfortunately, there is no way to fix this without changing an interface
function thFindVal(). As I could see thFindValue() cannot silent return
0 (not found, no care) it always calls Th_ErrorMeesage() on fails.
I tested some workaround, it does not change default behavior and other
Th_*Var() are happy, please, look on a draft patch (original comments
have not been fixed). Could we expand 'arrayok' flag to a bitfield flag
or that is ugly thing?
Thank you for your time.
Sergei
Index: src/th.c
==
--- src/th.c
+++ src/th.c
@@ -1042,10 +1042,16 @@
*pnInner = nInner;
*pisGlobal = isGlobal;
return TH_OK;
}
+#define FV_ArrayOk0x0001
+#define FV_NoError0x8000
+
+#define FIND_ARRAYOK 0x0001
+#define FIND_NOERROR 0x8000
+
/*
** Input string (zVar, nVar) contains a variable name. This function locates
** the Th_Variable structure associated with the named variable. The
** variable name may be a global or local scalar or array variable
**
@@ -1060,11 +1066,11 @@
static Th_Variable *thFindValue(
Th_Interp *interp,
const char *zVar, /* Pointer to variable name */
int nVar, /* Number of bytes at nVar */
int create,/* If true, create the variable if not found */
- int arrayok/* If true, an array is Ok. Otherwise array==error */
+ int flags
){
const char *zOuter;
int nOuter;
const char *zInner;
int nInner;
@@ -1114,20 +1120,22 @@
pValue = Th_Malloc(interp, sizeof(Th_Variable));
pValue-nRef = 1;
pEntry-pData = (void *)pValue;
}
}else{
-if( pValue-pHash !arrayok ){
+if( pValue-pHash (flagsFV_ArrayOk)!=FIND_ARRAYOK ){
Th_ErrorMessage(interp, variable is an array:, zOuter, nOuter);
return 0;
}
}
return pValue;
no_such_var:
- Th_ErrorMessage(interp, no such variable:, zVar, nVar);
+ if( (flagsFV_NoError)!=FIND_NOERROR ){
+Th_ErrorMessage(interp, no such variable:, zVar, nVar);
+ }
return 0;
}
/*
** String (zVar, nVar) must contain the name of a scalar variable or
@@ -1154,11 +1162,11 @@
/*
** Return true if variable (zVar, nVar) exists.
*/
int Th_ExistsVar(Th_Interp *interp, const char *zVar, int nVar){
- Th_Variable *pValue = thFindValue(interp, zVar, nVar, 0, 0);
+ Th_Variable *pValue = thFindValue(interp, zVar, nVar, 0, FIND_NOERROR);
return pValue pValue-zData;
}
/*
** String (zVar, nVar) must contain the name of a scalar variable or
Index: test/th1.test
==
--- test/th1.test
+++ test/th1.test
@@ -132,10 +132,15 @@
###
fossil test-th-eval set var 1; unset var; expr {\$var+0}
test th1-info-exists-5 {$RESULT eq {TH_ERROR: no such variable: var}}
+
+###
+
+fossil test-th-eval catch foo; info exists bar; set ::th_stack_trace
+test th1-info-exists-6 {$RESULT eq {foo}}
###
fossil test-th-eval set var 1; unset var
test th1-unset-1 {$RESULT eq {var}}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] relative tags
Fossil has the special tag previous and next to refer to the 2 commits on either sire of the current check out. It would be useful to be able to refer to more distant commits. I am thinking numbers prefixed with either '-' or '+', so '-r -1' would be equivalent to '-r previous', '-r -2' would be the commit before that, etc. Likewise, '-r +1' == '-r next', '-r +2' the one after that, etc. Thanks ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Version 1.28 release?
A while back when considering Fossil, I read that 'any' database could have been chosen in its design. This thread seems to contradict Fossil's published design theme? http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki Thoughts On The Design Of The Fossil DVCS: We claim that Fossil is not based on SQLite at all and that Fossil is not based on a distributed NoSQL database because Fossil is a distributed NoSQL database. Fossil Is A NoSQL Database We begin with the first question: Fossil is not based on a distributed NoSQL database because Fossil *is* a distributed NoSQL database. Fossil is *not* based on SQLite. The current implementation of Fossil uses SQLite as a local store for the content of the distributed database and as a cache for meta-information about the distributed database that is precomputed for quick and easy presentation. But the use of SQLite in this role is an implementation detail and is not fundamental to the design. Some future version of Fossil might do away with SQLite and substitute a pile-of-files or a key/value database in place of SQLite. (Actually, that is very unlikely to happen since SQLite works amazingly well in its current role, but the point is that omitting SQLite from Fossil is a theoretical possibility.) I treat Fossil as a standalone and critical app and believe it deserves higher standing than a test bed for SQLite. Thanks for Fossil and SQLite! On Thu, Jan 9, 2014 at 11:52 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Jan 9, 2014, at 16:35 , sky5w...@gmail.com wrote: Took time to reply, cause I had to clean the coffee I spit up! A released application should be considered stable and a conservative view would say its libs should not contain alphas or betas. The ease of compiling a bleeding edge Fossil.exe is already in place for those wishing to gain the latest features in trunk. You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. SQLite QA is so impressive that some may be pretty comfortable with having any version, provided it has passed a full test suite, included in their systems. The problem here is the message sent by the word alpha. What it usually means is I just wrote it, hope it will not explode in your face, but no warranties. Therefore if we want to say Fossil is rock-solid, we can't say it uses alpha libs, just to avoid the confusion, no matter the actual quality. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
On Thu, Jan 9, 2014 at 8:05 AM, Mark Janssen mpc.jans...@gmail.com wrote: ... The reflected information in the query is the info from before the ticket update. I suspect the ticket hook is fired before the actual ticket change transaction is commited. Would it be possible to reverse this so that the hook script will be executed after the ticket change has been commited? Actually, how about 2 hooks, one before and one after? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small issue with ticket hook script
On Thu, Jan 9, 2014 at 5:58 PM, Mark Janssen mpc.jans...@gmail.com wrote:
On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
I have a different fix
in mind, I'll come back on that later.
http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook
Does this work for you?
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
No with this a ticket change from the web UI will not trigger the xfer
script.
With change below it works again is rc what you think it is at that part in
the code? I would think that a single ticket hook script failure should not
terminate all of them.
--- src/manifest.c
+++ src/manifest.c
@@ -1506,13 +1506,11 @@
}
db_prepare(q, SELECT uuid FROM pending_tkt);
while( db_step(q)==SQLITE_ROW ){
const char *zUuid = db_column_text(q, 0);
ticket_rebuild_entry(zUuid);
-if( rc==TH_OK ){
- rc = xfer_run_script(xfer_ticket_code(), zUuid);
-}
+rc = xfer_run_script(xfer_ticket_code(), zUuid);
}
db_finalize(q);
db_multi_exec(DROP TABLE pending_tkt);
/* If multiple check-ins happen close together in time, adjust their
___
fossil-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 1/9/2014 07:31, Richard Hipp wrote: But I want Fossil to follow the latest SQLite alphas, So run sqlite.org with Fossil + SQLite alpha. Everyone is free to run Fossil in any configuration they like. Please don't ask the rest of the Fossil user community to alpha-test SQLite for you, using their precious source archives as cannon fodder. SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? ___ fossil-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 9, 2014 at 3:15 PM, Warren Young war...@etr-usa.com wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? -- 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
Re: [fossil-users] Version 1.28 release?
On 1/9/2014 13:17, Richard Hipp wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? I'll take you at your word. I'm not going to go trawl the SQLite changelog to try and prove you wrong. I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. I have no problem with you asking people to volunteer for such a test. [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. ___ fossil-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: set v 0; unset v; info exists v;
Sergei Gavrikov wrote: Thank you for the fixes! I'm sorry, but, I found yet another issue with Th_ExistsVar(). If a variable is not exists, Th_ExistsVar() does clear TH stack trace: Thanks again, fixed here: https://www.fossil-scm.org/index.html/info/9765b03759 -- Joe Mistachkin ___ fossil-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 9, 2014 at 3:28 PM, Warren Young war...@etr-usa.com wrote: I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. The fact that you feel this way (and that you probably represent the views of many others who haven't bother to comment) shows that Jan is correct, and that we really need to back up to the last version of SQLite that is deemed stable for the release. -- 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
Re: [fossil-users] Version 1.28 release?
On Jan 9, 2014, at 21:28 , Warren Young wrote: On 1/9/2014 13:17, Richard Hipp wrote: SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? Yes, I am. Are you aware of any that I missed? I'll take you at your word. I'm not going to go trawl the SQLite changelog to try and prove you wrong. I'm just uncomfortable being conscripted into someone else's alpha testing program, especially when that test involves my work product, purposely stored in a central location[*] for archival purposes. Exactly my point about message sent by the alpha word. [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. The fact that Fossil is sort of write-only should. By design Fossil does not allow changing (thus destroying) any historical records. The only unwanted thing that can conceivably propagate is your CC number in a test file. If you are concerned by new software errors eating your code, simply don't update your central location. Fossil can easily interoperate in the distance of many versions. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'
version 1.28 [6f1b5d6047] gives me memory faults when doing something like `fossil search whatever' #search pattern does not matter ... when executing it on fossil's own timeline (i.e. in a checkout of the `fossil' source code). observed under MacOS 10.8.5. it seems to be related to the length of the timeline. `search' works just fine for smaller projects. can someone confirm this behaviour? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-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 [6f1b5d6047] memory faults at `fossil search'
On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff veedeeh...@googlemail.comwrote: version 1.28 [6f1b5d6047] gives me memory faults when doing something like `fossil search whatever' #search pattern does not matter ... when executing it on fossil's own timeline (i.e. in a checkout of the `fossil' source code). observed under MacOS 10.8.5. it seems to be related to the length of the timeline. `search' works just fine for smaller projects. can someone confirm this behaviour? Confirmed. Fixed now. On trunk and on the 1.28 branch. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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
Re: [fossil-users] Version 1.28 release?
Am Donnerstag, 9. Januar 2014, 13:15:30 schrieb Warren Young: On 1/9/2014 07:31, Richard Hipp wrote: But I want Fossil to follow the latest SQLite alphas, So run sqlite.org with Fossil + SQLite alpha. Everyone is free to run Fossil in any configuration they like. Please don't ask the rest of the Fossil user community to alpha-test SQLite for you, using their precious source archives as cannon fodder. +1 SQLite alphas are more robust that stables of most other software projects. Are you asserting that no data-destroying bugs have ever appeared in a SQLite alpha? ___ 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] Version 1.28 release?
On Jan 9, 2014, at 21:38 , Remigiusz Modrzejewski wrote: [*] The fact that Fossil is a DVCS doesn't ease my mind on this matter. All that means is that if there ever is a data loss, it will take some time to propagate among the copies, during which time I *may* catch it in time to recover, before the last copy gets tainted. The fact that Fossil is sort of write-only should. What I meant is obviously append-only. By design Fossil does not allow changing (thus destroying) any historical records. The only unwanted thing that can conceivably propagate is your CC number in a test file. If you are concerned by new software errors eating your code, simply don't update your central location. Fossil can easily interoperate in the distance of many versions. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'
On Thu, 09 Jan 2014 22:01:07 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 3:54 PM, j. van den hoff veedeeh...@googlemail.comwrote: version 1.28 [6f1b5d6047] gives me memory faults when doing something like `fossil search whatever' #search pattern does not matter ... when executing it on fossil's own timeline (i.e. in a checkout of the `fossil' source code). observed under MacOS 10.8.5. it seems to be related to the length of the timeline. `search' works just fine for smaller projects. can someone confirm this behaviour? Confirmed. Fixed now. On trunk and on the 1.28 branch. thanks for this. question: the output of `fossil search' is not chronologically sorted. it should be in my view (top down, that is, from new to old just as the timeline). is this intended behaviour? another observation: I see strange hits in the search. e.g. (still for the fossil timeline) `fossil search abc' yields (upon others, obviously correct hits) a hit for rev. 94694585cd which seemingly is a commit with an empty commit message... looks like a bug to me. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-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, 9 Jan 2014 15:35:06 -0500 Richard Hipp d...@sqlite.org wrote: The fact that you feel this way (and that you probably represent the views of many others who haven't bother to comment) shows that Jan is correct, and that we really need to back up to the last version of SQLite that is deemed stable for the release. I trust your QA of Fossil, but, at the same time, wishing that Fossil become spread more widely, believe it's better not to be 'shipped' with alpha-labelled SQLite code. Sincerely, Gour ___ fossil-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 [6f1b5d6047] memory faults at `fossil search'
On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: thanks for this. question: the output of `fossil search' is not chronologically sorted. it should be in my view (top down, that is, from new to old just as the timeline). is this intended behaviour? another observation: I see strange hits in the search. e.g. (still for the fossil timeline) `fossil search abc' yields (upon others, obviously correct hits) a hit for rev. 94694585cd which seemingly is a commit with an empty commit message... looks like a bug to me. Yeah. The whole fossil search command was an idea that I tried several years ago. But I didn't spend enough time on it to drive it to completion. It needs attention. Do we have your contributor's agreement on file? Wanna help? -- 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
Re: [fossil-users] 1.28 [6f1b5d6047] memory faults at `fossil search'
On Thu, 09 Jan 2014 23:24:33 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 9, 2014 at 5:19 PM, j. van den hoff veedeeh...@googlemail.comwrote: thanks for this. question: the output of `fossil search' is not chronologically sorted. it should be in my view (top down, that is, from new to old just as the timeline). is this intended behaviour? another observation: I see strange hits in the search. e.g. (still for the fossil timeline) `fossil search abc' yields (upon others, obviously correct hits) a hit for rev. 94694585cd which seemingly is a commit with an empty commit message... looks like a bug to me. Yeah. The whole fossil search command was an idea that I tried several years ago. But I didn't spend enough time on it to drive it to completion. It needs attention. Do we have your contributor's agreement on file? Wanna help? would if I could. but I'm afraid I'm not so much of a C programmer these days. for now, my 'solution would be to use `fossil timeline -n 0 -W 0 | grep pattern' ...). anyway, if you let me know where to look exactly I might give it a try if I get around to it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-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: set v 0; unset v; info exists v;
On Thu, 9 Jan 2014, Joe Mistachkin wrote: Sergei Gavrikov wrote: Thank you for the fixes! I'm sorry, but, I found yet another issue with Th_ExistsVar(). If a variable is not exists, Th_ExistsVar() does clear TH stack trace: Thanks again, fixed here: https://www.fossil-scm.org/index.html/info/9765b03759 Thank you! Sergei ___ fossil-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?
Am 09.01.2014 17:52, schrieb Remigiusz Modrzejewski: You do realize that alpha and beta are just words? With different quality assurance procedures in different projects, trying to use them as a gauge of anything else than releaser intent is misleading. Well, can I come in here? Maybe alpha and beta are just words, but they are used for a reason. The reason is, that the software in these states is not fully tested and not to be considered stable. Therefore the software should not under any circumstances be used in productive environment. So please, if anyone is going to give a stable release, do not use alpha or beta dependencies on it, because that makes your software alpha or beta for a reason. There is nothing that tells me, if I'm using a stable release of fossil, if my repository is getting fucked up by a feature from the alpha/beta sqlite. Maybe sqlite has a very very good QA and the software is extremly stable, but even the own developers do not trust the version as stable - so why should we? regards, Oliver ___ fossil-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 cut first charracter of the filename
Hello, Perhaps having fossil manage files outside its own root is not practical to implement/want, I don't know. And can be very confusing and dangerous. I suppose, in that case instead of this reaction: if I change the name of the directory, I don't get error, but the name of file is transformed: /test1# fossil add ../opt1/one.txt ADDED ne.txt there should be a nice message informing the user about the fact that adding a file from a upper directory is a bad idea. i think, it would be right to register current behaviour as a bug. A. Shtine 09.01.2014 13:33, Martin Gagnon пишет: On Thu, Jan 09, 2014 at 10:45:35AM +0100, Michai Ramakers wrote: Hello, On 9 January 2014 09:43, shtine sht...@runway.lv wrote: Hello, Perhaps the error is a bit misleading... Should it be possible to add files that are above the root of the open fossil repository? This would be a nice feature to have. I want to use fossil to manage changes on linux based VPN Routers. Some of my config files live in /etc , some in /opt/scripts. It would be nice to be possible to run fossil from something like /opt/archive. Currently, for my purposes, I can only run it from (/) root directory which is not so flexible. Perhaps having fossil manage files outside its own root is not practical to implement/want, I don't know. And can be very confusing and dangerous. Imagine working from /a/b/c/d/e/f/g/checkoutdir and adding file ../../../../../file.txt. Later, one open a checkout in /a/b. Where file.txt will go ? Or the file could also goes inside another checkout, a clean in this other checkout could delete latest change. [snip] Actually, latest version of trunk work for a checkout on '/', which was not the case before. It is less flexible for you to work on '/' but could be use. In my case I don't do that on my workstation but on some headless BSD server where I want to track changes on system configuration files. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
