[fossil-users] warning fix
Fix for:
../src/http_transport.c: In function ‘test_ssh_far_side_cmd’:
../src/http_transport.c:271:13: warning: ignoring return value of ‘system’,
declared with attribute warn_unused_result [-Wunused-result]
Sergei
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -266,11 +266,11 @@
while( isizeof(zLine) ){
got = read(0, zLine+i, 1);
if( got==0 ) return;
if( zLine[i]=='\n' ){
zLine[i] = 0;
- system(zLine);
+ if( system(zLine)==-1 ) return;
i = 0;
}else{
i++;
}
}
___
fossil-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 json stat output
see RFC-ed area...
On Mon, Feb 18, 2013 at 9:38 AM, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Feb 18, 2013 at 4:51 PM, Stephan Beal sgb...@googlemail.comwrote:
On Mon, Feb 18, 2013 at 3:50 PM, Stephan Beal sgb...@googlemail.comwrote:
Hi, Ross, Pirate, und Co.,
Request for comments: how should the list of file-level changes be
structured for the output? Here are the options which come to mind (but
feel free to suggest something else):
For a bit more context...
[stephan@host:~/cvs/fossil/fossil/src]$ f json status
{
fossil:b27c0d6d3fd0abe50a14e85b557f16fdbab94fab,
timestamp:1361205119,
command:status,
procTimeMs:4,
payload:{
repository:/home/stephan/cvs/fossil/fossil.fsl,
localRoot:/home/stephan/cvs/fossil/fossil/,
checkout:{
uuid:b27c0d6d3fd0abe50a14e85b557f16fdbab94fab,
datetime:2013-02-18 13:46:41 UTC,
timestamp:1361195201
}
data Items I would like to see in the payload. thanks...
branch:trunk,
add: [add_file_1, add_file_2],
edit: [edited_file_1, edited_file_2],
extra: [extra_file_1, extra_file_2],
tags: [tag_name_one, tag_name_two],
}
}
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How to do incremental update after clone from other VCS?
Hi, I've started evaluating Fossil as a replacement for other VCSes (to import from existing codebase, and possibly to maintain a repository to keep in sync during a transition, experimental phase). Trying the recipe in the Fossil Cookbook with a substantially larger codebase (CPython's Mercurial repository, which yields a fairly large work, lasting about 1 full day to complete the generation!) I realized that after doing that I'd like to keep the Fossil repository in sync (commit logs, changes, etc.) with the commits from the original VCS (imports only, it's a one-way sync). So far, with this exercise, I managed that I should be doing a # hg pull hg update on the Mercurial side (yes, I'm a total Mercurial and Git newb and I'm fumbling around trying to find a sensible recipe). I imagine that at the Fossil end I'm supposed to use a --incremental switch when I do something like fossil import --git myrepo.fossil IncrementalBlob.git after generating a IncrementalBlob.git file with git-fast-export. But the in-between those two points, I don't understand enough about which options to use on hg-fast-export and git-fast-export to select only the necessary revisions to produce the blob with which to do a fossil incremental import. Has anyone done something similar already? Can you please assist with the options to apply to git to generate the incremental export I'm supposed to use for a successful fossil incremental import? Thanks in advance. J. Batista. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Feature requests: fossil ui and server improvements
1. If I say fossil ui and the browser starts successfully and then
exits, Fossil should exit, too. It should arguably exit even if it
fails to start the browser, since you asked for a UI and it couldn't
provide one.
I gather that it behaves the way it currently does because fossil
server was added later, and before that point, fossil ui was the only
way to get Fossil to act as a web server. That makes this stay
running behavior of fossil ui vestigial now, no? If I want Fossil to
remain running to provide network service, I should use fossil server
not fossil UI, right?
2a. It would be nice if fossil server had a -A address flag to make
it bind to a particular network interface, for use on multihomed
machines. We would like to use a machine with multiple IP aliases have
www.foo.com and fossil.foo.com in DNS, with Apache and Fossil both bound
to port 80 but on different IPs.
2b. It would also be nice to be able to set the HTTP_SERVER_LOCALHOST
internal flag with, say, fossil server -L, so that if you are proxying
access to Fossil, Fossil's listening port isn't directly accessible on
external network interfaces.
3. The enter_chroot_jail() stuff seems to be broken. I get this in the
browser if I try to run fossil server as root:
SQLITE_CANTOPEN: cannot open file at line 28175 of [7e10a62d0e]
SQLITE_CANTOPEN: os_unix.c:28175: (2) open(/server.fossil-journal) - No such
file or directory
SQLITE_CANTOPEN: statement aborts at 25: [INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://mongo:82',1,now())]
Database Error
unable to open database file: {INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://mongo:82',1,now())}
If you have recently updated your fossil executable, you might need to run fossil
all rebuild to bring the repository schemas up to date.
I guess someone has messed up the order of operations here, so that the
DB isn't open by the time it tries this, hence why the DB's journal
doesn't yet exist. It's probably a good thing for the DB to not be
opened until after root privileges are dropped.
The only reason I'm trying to run Fossil as root is so I can bind it to
port 80, without using a reverse proxy.
I've tried both v1.24 and the fossil trunk:
This is fossil version 1.25 [646c4a67f9] 2013-02-19 12:29:39 UTC
4. It would be nice if Fossil would probe for the existence of X11 on
*ix type systems before attempting to start the browser. The code in
this question should work:
http://stackoverflow.com/questions/637005/x-server-running
I mention it because I'm writing a script that calls either fossil ui
or fossil server depending on whether a GUI is available. Checking
$DISPLAY isn't good enough because my Windows SSH client sets that
variable regardless of whether I have X running. (X sometimes *is*
running on the Windows box. Just not all the time.) So, Firefox tries
to run on my Linux server, thinking it can display on my Windows box, so
my SSH client spams me with errors that it could not forward packets to
the local X server until Firefox gives up and dies.
Fossil should check that $DISPLAY exists first, of course, so it doesn't
get confused on Cygwin and Mac systems, where it may find X libraries at
configure time, but where X is often not running.
I'm currently hacking around this in my script by attempting xterm -e
exit before fossil ui, since that results in only *one* error when X
isn't running.
___
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 svn conversion gets confused if last svn checkin is on a branch
I'm currently working through the conversion of a 14 year old (!) svn repo to Fossil, and ran into dodgy behavior in one of the iterations. Over the years, we've changed how we named branches and tags a few times. We had a mess like this: mms5_00 mms6.3 mms-7.0 mms-v8 Dash or no dash, 'v' or no 'v', underscores vs dots... We can more easily ignore messes like this with svn than with Fossil, since you have to go poking around in the branches subdirectory to see it in svn, whereas in Fossil, it's right there in the main UI. So, we decided to clean these up in svn before converting to Fossil, since Fossil seems more aggressive about preserving history, no matter how distasteful. We did a bunch of svn mv file:///svn/branches/mms6.3 file:///svn/branches/mms-6.3 type stuff, then spent the 2 hours to convert the repo again. On looking at the Files tab in the Fossil UI after conversion, we saw that we only had a subset of the original repo files! Yet, the .fossil DB file was the same size as with the previous conversion, so clearly we didn't actually lose anything. We eventually figured out that Fossil was getting confused by the fact that the last svn checkin was on a branch instead of the trunk, and that branch held the file subset we saw in the Fossil Files tab. We fixed that by doing one last bogus checkin on the svn repo trunk, completely redid the conversion (another 2 hours), and now Fossil is showing the correct directory structure in the Files tab. The request, of course, is for the Fossil Git importer to either have some improvement that makes it smarter about recognizing the *true* trunk, or at least a flag that lets you tell it the trunk's tag name if it guesses wrong. By the way, you might be realizing that Fossil would now be showing both mms6.3 and mms-6.3 branches after my svn mv command above. But, we've fixed that with Git's history rewriting abilities, since we have to use it as an intermediary anyway. The two branches are pure aliases for one another, so there's no harm removing the one with the obsolete version naming scheme, right? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
