Re: [fossil-users] Why do we need a fossil hosting service?
On Tue, Apr 2, 2013 at 4:12 PM, Steve Havelka yo...@q7.com wrote: On 03/30/2013 02:59 AM, Stephan Beal wrote: On Sat, Mar 30, 2013 at 4:06 AM, Steve Havelka yo...@q7.com wrote: You're saying that Fossil is intended to be used by few people, or that Fossil is intended not to have a user community? Fossil _repos_ are indeed intended to be used by relatively few people at a time. Fossil is designed for small, relatively tight-knit teams. It does not directly support deep hierarchies of developers like git does. I think the original poster, in mentioning community and the momentum that can come with it, was not referring to the number of contributors to any given project. My suspicion is that most of the repositories on Github have one or a few contributors, too. I think--and speak up please, Matt, if I'm misinterpreting or have misunderstood you--that Matt was obliquely referring to how much better off a tool is when there are lots and lots of people using it, improving it, building auxiliary tools around it, thinking on it, etc. I think it'd be just grand if lots more people used Fossil, and brought their ideas, code, and improvements to the table too. I can't really see a downside to this. That's the sort of stuff that Github has helped do for git, that we'd do well to have built around Fossil. Yes, although lots of contributors to a single project might be great and might need the features that git provides that is not the collaborative energy I'm referring to. It is more that there are lots of people browsing github, using git itself, and, occasionally, finding interesting projects and forking them and making contributions. I think that fossil will grow into a better tool with more widespread use and a hosting service with some features that make participating in existing projects in a detached way (i.e. unblessed forks) could contribute to that growth. Because it is easier to use than git (at least in my opinion) fossil does have an opportunity here to grow if the existing community wants to make that happen. It seems to me that unblessed forks could be supported within the same repository with by adding some optional features: 1. Allowing logged in users to create branches with their user name as the prefix. 2. Adding branch name pattern filtering to sync. 3. Adding a mechanism to shun based on branch name. A project owner could turn on the name-prefix branches to enable unblessed contributions. People could sync everything or just the things they want using the branch filtering. Cleaning up after a mistake or obnoxious user would be as simple as shunning all on that branch. I know that the database uses deltas and it I suspect some of these actions might require some non-trivial re-processing of stored data but it does seem technically feasible and might be worth considering for implementation one day. . -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://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] ssh fails on second sync when ?shell=/bin/bash option used
The initial sync works (it properly uses the shell=/bin/sh) but subsequent sync's fail as the shell then reverts to fossil. Even if I set the url in the fossil database to include the shell=/bin/sh it still gets ignored. To work around this I've compiled my own version of fossil with the remote shell hard coded to /bin/sh I'm also getting two Killed by signal 2. messages on a commit. This is very disconcerting to users and I think it would be good to suppress those messages. Is there a trick to get the remote shell overriding to work consistently? I'm using version-1.25. Thanks, Matt -=- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Chiselapp.com shutting down
One thing that would be really nice IMHO would be to provide a mechanism to derive a repo from an existing one and have that connection clear and visible on the site. This would have to be optional. Having support for this inside a single fossil would be ideal from my perspective but I understand that is not a popular point of view. Just my $0.02. On Fri, Mar 29, 2013 at 4:55 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Mar 29, 2013 at 12:48 AM, Timothy Beyer bey...@fastmail.netwrote: At Thu, 28 Mar 2013 20:52:59 -0400, James Turner wrote: After a couple weeks of debate, I've decided to shut down Chiselapp.com. I think that the Fossil project should aim to have at least one official host to replace chiselapp. Yes, I suppose there really ought to be a hosting service for Fossil someplace So I'm exploring the option of setting up a new one. The first decision is (1) whether to use James' Flint code base or (2) write my own. Those who know me recognize that I would tend toward (2). (Were it not for this tendency, Fossil and SQLite might not exist, after all.) Suppose I did write my own hosting system. What is is required for that. (James, you have the most experience with this question, so your input is especially encouraged!) (1) Some means for people to create accounts (2) Some means for people to upload Fossil repositories to hosted (3) Per-account bandwidth tracking? (4) Require advertising (example http://system.data.sqlite.org/) for unpaid accounts? (5) Require unpaid accounts to be open-source? (6) Some mechanism to accept payment for private or add-free accounts? (7) Procedures to deal with DMCA takedown requests? What else is needed? James, what are your bandwidth, cpu, and disk space requirements? (You can send me that via private email if you prefer.) -- 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] Why do we need a fossil hosting service?
for what it's worth as compared to github you are missing: Ability to browse and discover projects based on searches, tags and developer. Ability for loosely coupled collaboration (i.e. fork). Community and the momentum that can come with it. Project life beyond the initial developer. On Fri, Mar 29, 2013 at 9:29 AM, James Bremner ja...@ravenspoint.comwrote: Just wondering why we need a dedicated fossil hosting service. I have managed for years without. For example: Copy fossil repository to dropbox folder; make folder publicly available, or privately share it. Done! Am I missing something? James __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] ssh transport and tcsh
It looks like trying to override both the shell and the fossil
location works only for the initial clone. There is a problem with
using to separate the second parameter so a sync done later fails.
/opt/bin/fossil remote-url
'ssh://localhost:22///tmp/fossils/testing.fossil?fossil=/opt/bin/fossilshell=/usr/bin/bash'
Everything after the seems not to be stored by fossil.
For now I use the fossil I compiled where I forced the shell. Can the
remote-url storage escape the or is there an alternate character
that can be used?
On Wed, Feb 6, 2013 at 7:05 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Feb 6, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 6:22 PM, Matt Welland estifo...@gmail.com wrote:
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
I want to understand the problem before I put in the fix.
To try to help better understand what is happening, I have added a new query
parameter to the ssh: url scheme. You can now say:
fossil clone ssh://user@host/path/to/repo?shell=/bin/bash new.fossil
and that will cause Fossil to add the /bin/bash argument to the end of the
ssh command. Please note that you can also do --sshtrace to get some
interactive information on what the ssh command is doing.
This idea seems good to me. I'll test it tomorrow. Thanks!
On my debian system, the clone hangs with shell=/bin/tcsh and with
shell=/bin/sh but works with shell=/bin/bash. Except if I also add the
--httptrace argument, then all three work. The --httptrace argument
disables compression of the content moving over the wire. So perhaps the
problem is that with compression turned on you occasionally get binary 0x00
bytes moving over the wire, which confuses /bin/tcsh and /bin/dash but not
/bin/bash. Just a guess.
I did try stty raw thinking it might be xon/xoff or other
handshaking but got errors with the command.
Note that you have long had a query parameter
fossil=/path/to/fossil/on/remote/system with the ssh: scheme that lets you
specify a particular version of fossil to run on the remote system. At
least on my machine, my fossil binaries is not on the path set up by .cshrc,
so I also have to manually specify the location of the fossil binary if I
change from using /bin/bash.
Yep, I used the ?fossil= to do my testing. This approach with the
query parameters is very useful.
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
--
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] Is it possible to increase the sqlite timeout for fossil?
We are getting a *lot* of collisions in heavy use repos. Rather than confusing sync errors I'd like it if fossil just waited longer for the repo to come available. I think setting a 10 second timeout on sqlite would make a huge difference here. Can this be done? 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] Is it possible to increase the sqlite timeout for fossil?
Interesting that the timeout is already 5 seconds. What happens is
sync fails and then users are confused. Perhaps this is not a timeout?
Note that this is direct file system access. I think suppressing the
sqlite3 error would help and a try again? Y/n prompt.
This is what we see:
New_Version: 5df265af2129cc9d526860abc5897d084aa5ae25
Autosync: file://.blah.fossil
Bytes Cards Artifacts Deltas
Sent:5152 71 0 4
Error: Database error: unable to open database file
INSERT INTO rcvfrom(uid, mtime, nonce, ipaddr)VALUES(1,
julianday('now'), NULL, '127.0.0.1')
Received: 159 1 0 0
Total network traffic: 2854 bytes sent, 348 bytes received
fossil: Autosync failed
Stat output:
Repository Size: 214505472 bytes
Number Of Artifacts: 18929 (stored as 7411 full text and 11518 delta blobs)
Uncompressed Artifact Size: 108372 bytes average, 528150528 bytes max,
2051280245 bytes total
Compression Ratio: 9:1
Number Of Check-ins: 3411
Number Of Files: 14198
Number Of Wiki Pages: 11
Number Of Tickets: 30
Duration Of Project: 743 days or approximately 2.03 years
Project ID: b711128a80477cdb2f9a91b663dd6b2e8083c0b0
Server ID: b7aa6d92b218bd8086de653d1b7b58d7fac84c02
Fossil Version: 1.22 2012-03-19 12:45:47 [5dd5d39e7c] (gcc-4.4.1)
SQLite Version: 2012-03-16 00:28:11 [74eadeec34] (3.7.11)
Database Stats: 209478 pages, 1024 bytes/page, 113 free pages, UTF-8,
delete mode
On Thu, Feb 21, 2013 at 8:36 AM, Richard Hipp d...@sqlite.org wrote:
On Thu, Feb 21, 2013 at 10:24 AM, Matt Welland estifo...@gmail.com wrote:
We are getting a *lot* of collisions in heavy use repos. Rather than
confusing sync errors I'd like it if fossil just waited longer for the
repo to come available. I think setting a 10 second timeout on sqlite
would make a huge difference here. Can this be done?
Timeout is currently 5 seconds:
http://www.fossil-scm.org/fossil/artifact/35a237cbfde?ln=723
You could change that and recompile. But before you do, first make sure you
are in WAL mode. Can you post the /stat page for your repository - the
equivalent of (http://www.fossil-scm.org/fossil/stat)?
Thanks.
___
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] Is it possible to increase the sqlite timeout for fossil?
On Thu, Feb 21, 2013 at 9:25 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Feb 21, 2013 at 11:21 AM, Matt Welland estifo...@gmail.com wrote: Database Stats: 209478 pages, 1024 bytes/page, 113 free pages, UTF-8, delete mode That delete mode notation on the end denotes the problem. You need to change your repository on the server to WAL mode. Do this as follows: sqlite3 $repository 'pragma journal_mode=wal' Or fossil rebuild $repository --pagesize 8192 --wal The second method will take (much) longer, but it also changes the page size from 1024 bytes to 8192 bytes, which won't make a huge difference but will help some. We can't switch to WAL mode currently as these repos are accessed from multiple machines via NFS. Now that ssh is working for us we can convert over to using ssh to a central server and switch to WAL mode at the same time. Is there any downside to using ssh? How dramatic is the performance improvement with WAL mode? Thanks. -- 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] ssh transport and tcsh
Hmmm... your point about the remote login is curious. I assumed that fossil was doing something like this (I'm using faux code here): inport, outport = popen2(ssh, -e, none, user@host, fossil, ... ) but it sounds like what is actually being done is (I have not grokked the code well enough to confirm yet) the following: inport, outport = popen2(ssh, -e, none, user@host, /bin/sh) ... print outport fossil ... params and the hypothesis is that svn and hg use the first approach which bypasses whatever the issue is with tcsh? Aside, I read the man page but don't understand why /bin/sh is in the call to execl twice. The second call seems to be running zCmd as a comand. Is this to deal with shell escaping hell? execl(/bin/sh, /bin/sh, -c, zCmd, (char*)0); On Wed, Feb 6, 2013 at 10:56 AM, j. van den hoff veedeeh...@googlemail.comwrote: On Wed, 06 Feb 2013 18:48:01 +0100, Matt Welland estifo...@gmail.com wrote: Using ssh for transport still doesn't work if a users login shell is tcsh. I'm looking for help on this problem as I've not yet found a solution. If anyone can confirm that the problem exists or if anyone has yes, I can confirm this (ssh transport not working with `tcsh'), both, under Ubuntu and MacOSX. matter of taste whether this is a `fossil' problem or a `tcsh' problem. I believe it has to do whith the fact that fossil actually is doing a remote login (not just executing a command via ssh as `svn' and `hg' are doing if I understand correctly). maybe with a little help from the developers the problem could be narrowed down somewhat and then brought to the attention of the tcsh maintainers? suggestions or insights as to what the problem might be it'd be much appreciated. To reproduce on Ubuntu just do the following: 1. Test ssh. The following command should complete without prompting for a password (you may get the authentication popup just once): ssh localhost ls 2. Test with bash (this assumes your default shell is /bin/bash which on 99% of sane Linux systems it is. This command would clone ~/foo.fossil to ~/new.fossil fossil set ssh-command 'ssh -e none' fossil clone ssh://$USER@localhost//home/$** USER/foo.fossil?fossil=/home/$**USER/bin/fossil new.fossil 3. Test with tcsh sudo apt-get install tcsh chsh -s /bin/tcsh # Repeat the clone above after removing new.fossil The clone in step three will succeed some of the time but fail most of the time (it hangs). Thanks in advance. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] ssh transport and tcsh
On Wed, Feb 6, 2013 at 12:27 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Feb 6, 2013 at 2:18 PM, Matt Welland estifo...@gmail.com wrote: Hmmm... your point about the remote login is curious. I assumed that fossil was doing something like this (I'm using faux code here): inport, outport = popen2(ssh, -e, none, user@host, fossil, ... ) but it sounds like what is actually being done is (I have not grokked the code well enough to confirm yet) the following: inport, outport = popen2(ssh, -e, none, user@host, /bin/sh) ... print outport fossil ... params Fossil needs to run multiple commands. /bin/sh is convenient to do this. If that is a really serious problem for the occasional csh system, then we could, in theory, create a new fossil command to take care of that for us: fossil test-sh. Then run: popen2(ssh, -e, none, user@host, fossil, test-sh); It seems silly to have to duplicate the functionality of /bin/sh inside of Fossil though, doesn't it? Agreed! Also, this may or may not even fix the problem. Now that you describe this I realize I was assuming the problem was on the remote side. If it was the remote side then the popen call will have nothing to do with it since the /bin/sh is happening on the local side. The layers should be Local side: /bin/sh - ssh Remote side: /bin/tcsh - fossil I'd like to trick fossil into running exec fossil on the remote. It is just wild speculation but stdin/out is going though the tcsh instance on the remote and perhaps execing fossil will bypass the problem? I tried: blob_zero(cmd); blob_append(cmd, exec , -1); shell_escape(cmd, g.urlFossil); but get: ssh -t -e none localhost Pseudo-terminal will not be allocated because stdin is not a terminal. Use of this system by unauthorized persons or in an unauthorized manner is strictly prohibited Authentication successful. stty: standard input: Invalid argument Broken pipe: 2 Artifacts sent: 0 received: 130 At least it doesn't hang :) . Any suggestions? and the hypothesis is that svn and hg use the first approach which bypasses whatever the issue is with tcsh? Aside, I read the man page but don't understand why /bin/sh is in the call to execl twice. The second call seems to be running zCmd as a comand. Is this to deal with shell escaping hell? execl(/bin/sh, /bin/sh, -c, zCmd, (char*)0); That's the way execl() works. First argument is the filename of the new image. Second argument is argv[0]. Third argument is argv[1]. And so forth. There is no good reason to have argv[0] different from the filename of the new image - I think that capability is legacy. Ah, now it makes sense. Thanks. It never occurred to me that argv[0] might not actually be directly derived from the filename being executed. -- 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] ssh transport and tcsh
On Wed, Feb 6, 2013 at 3:12 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Feb 6, 2013 at 1:52 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 3:39 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Feb 6, 2013 at 12:27 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 2:18 PM, Matt Welland estifo...@gmail.comwrote:
Hmmm... your point about the remote login is curious. I assumed that
fossil was doing something like this (I'm using faux code here):
inport, outport = popen2(ssh, -e, none, user@host, fossil,
... )
but it sounds like what is actually being done is (I have not grokked
the code well enough to confirm yet) the following:
inport, outport = popen2(ssh, -e, none, user@host, /bin/sh)
...
print outport fossil ... params
Fossil needs to run multiple commands. /bin/sh is convenient to do
this. If that is a really serious problem for the occasional csh system,
then we could, in theory, create a new fossil command to take care of that
for us: fossil test-sh. Then run:
popen2(ssh, -e, none, user@host, fossil, test-sh);
It seems silly to have to duplicate the functionality of /bin/sh inside
of Fossil though, doesn't it?
Agreed! Also, this may or may not even fix the problem. Now that you
describe this I realize I was assuming the problem was on the remote side.
If it was the remote side then the popen call will have nothing to do with
it since the /bin/sh is happening on the local side.
The layers should be
Local side: /bin/sh - ssh
Remote side: /bin/tcsh - fossil
The command:
ssh -e none user@host /bin/sh
should cause /bin/sh to be run on the remote side, without a pseudo-tty.
So, I'm not sure where tcsh even comes into play here. Maybe if you try
changing the initialization command to:
ssh -e none user@host exec /bin/sh
Does that make a difference?
Yes. The following patch appears to fix the problem:
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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] ssh transport and tcsh
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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] ssh transport and tcsh
On Wed, Feb 6, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Feb 6, 2013 at 6:22 PM, Matt Welland estifo...@gmail.com wrote:
I got some help from a co-worker to test this fix. He ran 1000's of clones
with bash as a login shell and with tcsh as a login shell with zero
problems. Can a couple other folks test it and can it then get into the
official release (assuming no problems found)?
It would be a real boon for me and some of my co-workers to have this
working :)
I want to understand the problem before I put in the fix.
To try to help better understand what is happening, I have added a new query
parameter to the ssh: url scheme. You can now say:
fossil clone ssh://user@host/path/to/repo?shell=/bin/bash new.fossil
and that will cause Fossil to add the /bin/bash argument to the end of the
ssh command. Please note that you can also do --sshtrace to get some
interactive information on what the ssh command is doing.
This idea seems good to me. I'll test it tomorrow. Thanks!
On my debian system, the clone hangs with shell=/bin/tcsh and with
shell=/bin/sh but works with shell=/bin/bash. Except if I also add the
--httptrace argument, then all three work. The --httptrace argument disables
compression of the content moving over the wire. So perhaps the problem is
that with compression turned on you occasionally get binary 0x00 bytes moving
over the wire, which confuses /bin/tcsh and /bin/dash but not /bin/bash.
Just a guess.
I did try stty raw thinking it might be xon/xoff or other
handshaking but got errors with the command.
Note that you have long had a query parameter
fossil=/path/to/fossil/on/remote/system with the ssh: scheme that lets you
specify a particular version of fossil to run on the remote system. At least
on my machine, my fossil binaries is not on the path set up by .cshrc, so I
also have to manually specify the location of the fossil binary if I change
from using /bin/bash.
Yep, I used the ?fossil= to do my testing. This approach with the
query parameters is very useful.
Cheers,
Matt
The patch with junk eliminated, it is just one line change:
Index: src/http_transport.c
==
--- src/http_transport.c
+++ src/http_transport.c
@@ -222,10 +222,11 @@
zHost = mprintf(%s, g.urlName);
}
blob_append(zCmd, , 1);
shell_escape(zCmd, zHost);
fossil_print( %s\n, zHost); /* Show the conclusion of the SSH
command */
+blob_append(zCmd, exec /bin/sh, -1);
free(zHost);
popen2(blob_str(zCmd), sshIn, sshOut, sshPid);
if( sshPid==0 ){
fossil_fatal(cannot start ssh tunnel using [%b], zCmd);
}
--
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
--
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] howto `grep' through old revisions
I haven't read all of the messages in this thread so please pardon the top post and possible useless or redundant info but my lazy and oh so very wrong method of grepping an entire fossil repo is to use fossil export and some grepping. No need to put the whole expanded repo on disk. First find the mark record. I was looking for some code where I started using a transaction: $ fsl export |egrep '^data\s+[0-9]\s*$|^blob|^mark\s+:[0-9]+$|transaction'|less mark :1904 blob mark :1906 (with-transaction blob Then use grep to find the comment and check in info, in my case it was in tasks.scm around Oct 23 (just convert seconds to time): commit refs/heads/trunk mark :1909 committer matt matt 1319432626 + data 31 Monitor based runs working well from :1895 M 100644 :1896 Makefile M 100644 :1898 db.scm M 100644 :1900 runs.scm M 100644 :1906 tasks.scm M 100644 :1902 tests/Makefile M 100644 :1904 tests/megatest.config commit refs/heads/trunk mark :1915 committer matt matt 1319449002 + data 43 Added missing dashboard-guimonitor.scm file from :1909 On Mon, Jan 28, 2013 at 1:06 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote: this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? The very existence of naive patterns is the point. It is kind of a FAQ with the canonical answer being http://swtch.com/~rsc/regexp/regexp1.html. Joerg ___ 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] howto `grep' through old revisions
Sorry, didn't paste in the second grep: fsl export | grep -A 10 -B 10 :1906 On Tue, Jan 29, 2013 at 12:08 AM, Matt Welland estifo...@gmail.com wrote: I haven't read all of the messages in this thread so please pardon the top post and possible useless or redundant info but my lazy and oh so very wrong method of grepping an entire fossil repo is to use fossil export and some grepping. No need to put the whole expanded repo on disk. First find the mark record. I was looking for some code where I started using a transaction: $ fsl export |egrep '^data\s+[0-9]\s*$|^blob|^mark\s+:[0-9]+$|transaction'|less mark :1904 blob mark :1906 (with-transaction blob Then use grep to find the comment and check in info, in my case it was in tasks.scm around Oct 23 (just convert seconds to time): commit refs/heads/trunk mark :1909 committer matt matt 1319432626 + data 31 Monitor based runs working well from :1895 M 100644 :1896 Makefile M 100644 :1898 db.scm M 100644 :1900 runs.scm M 100644 :1906 tasks.scm M 100644 :1902 tests/Makefile M 100644 :1904 tests/megatest.config commit refs/heads/trunk mark :1915 committer matt matt 1319449002 + data 43 Added missing dashboard-guimonitor.scm file from :1909 On Mon, Jan 28, 2013 at 1:06 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote: this would not prevent, that people run into the exponential run time problem when using the naive pattern instead the anchored one, but this could be explained by a FAQ entry making the problem practically irrelevant. or do I still miss the relevant point? The very existence of naive patterns is the point. It is kind of a FAQ with the canonical answer being http://swtch.com/~rsc/regexp/regexp1.html. Joerg ___ 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] sqlite errors after reinstalling fossil
This problem doesn't look much like an issue with fossil itself. Perhaps trying a filesystem test suite would give you some hints as to the root cause? Google provided this link that might be a good starting point: http://nfsv4.bullopensource.org/doc/testing_tools.php Do things such as a kernel compile, video editing or other disk intensive tasks work fine? On Thu, Jan 17, 2013 at 3:32 PM, Joseph Mingrone j...@ftfl.ca wrote: The test user I created, whose home directory is set to the new filesystem with access times turned on, is also having the sqlite problems now. ___ 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] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 5:10 AM, Richard Hipp d...@sqlite.org wrote: On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland estifo...@gmail.com wrote: On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote: Curious response. Did you intend to be insulting? I'm working with a bunch of very smart people No insult intended. It's the smart people who have the greatest tendency to go heads down. I'm sorry that insult was inferred - my fault for sending a long and ranting post late on a Saturday night. Ok. Thanks. who are very reluctantly learning a new tool and a different way of doing things and forks are very confusing when they happen in a scenario where they seemingly should not. We are not operating in a disconnected fashion here. Fossil falls somewhat short in the support of people who like to get their job done at the command line (about 80% of users on my team). Distilling from the fossil timeline command that there is a fork and how to fix it is not easy. It is very tiresome to have to go back to the ui to ensure that a fork hasn't magically appeared. This is the part I don't understand, apparently: Your developers don't like to use the web interface to see what is happening? One quick glance at the web timeline would reveal the unintentional fork. These are busy repos. It sometimes takes me a minute to figure out what is happening so I agree it is most often a quick glance but not always. I'm not sure how to communicate the efficiency some people experience with a cli. Some people like vi, compile, test, examine history etc. all from one or two xterms and indeed I sometimes like this mode also. I personally find it a minor annoyance to have to bring up the ui, possibly because on a daily basis I'm dealing with five or more different fossil areas and keeping track of which ui goes with which task is distracting whereas if I'm working in an xterm with repoX then when I type in fossil timeline I know with 100% confidence in zero time that the timeline I'm looking at is for repoX. The ui will pop up another window that must be found in the myriad of windows with chip layout, schematics and other fossil repo ui's etc. already filling my desktop. The Fossil web interface is intended to aid developers in keeping track of what other team members are doing. Is there a reluctance among your people to use this interface? Please help me to understand the source of this reluctance so that I can try to address it. I think the fossil ui doe a great job, it is just the nature of yet another window to deal with that is an issue for some (I'm speculating here but know that this is sometimes true for myself). Anyhow, I misunderstood the exact nature of the cause. I assumed that the race condition lay within the users fossil process between the time the db query that checked for leaf and the insertion of the new checkin data in to the db. That is of course incorrect. The actual cause is that the central database is free to receive a commit via sync after having just done a sync that informs the users fossil process that it is fine to commit. Something like the following: User1 User2central sync leafcheck sync commit leafcheck synccommit receives delta from user1 just fine sync receives delta from user2 and now a fork exists As you point out below that is very difficult if not impossible to fix. What I think would alleviate this issue would be a check for fork creation at the end of the final sync. If a fork is found notify the user so it can be dealt with before confusion is created. OK. Right now the first sync is really just a pull, and the second is really just a push. But it is no big deal to change the second to a full sync. Then, you think it should issue a warning if there is another open leaf on the same branch? A quick check shows that this would causes warnings every time we check into the Fossil trunk, as there are a few abandoned trunk leaves: (1) http://www.fossil-scm.org/fossil/timeline?c=4c931047ef (2) http://www.fossil-scm.org/fossil/timeline?c=b41feab774 (3) http://www.fossil-scm.org/fossil/timeline?c=9503a9152e These leaves would have to be closed to silence the warnings. I'm guessing that every long-running project would have a few abandoned trunk leaves like this. Or, maybe the warning should only complain if the fork involved two check-ins occurring within a small amount of time of each other? Say, for example, that the warning only appears if the other leaf is within the previous 50 commits? There might be some minor transition pain where a bit of clean up of old repos would be necessary. I personally feel that keeping it simple and encouraging a clean history is good. If you have an old fork in the repo convert it to a branch and annotate appropriately. Using a heuristic such as the last 50 commits is sure
Re: [fossil-users] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 6:58 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp d...@sqlite.org wrote: http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg I'll see what I can do about enhancing Fossil with an approaching puma warning (warnings that a fork has occurred) and a shoot puma with sidearm command (fossil merge with no argument). Latest Fossil on trunk contains two new features: (1) Typing just fossil merge without a version argument will attempt to merge any forks that exist on the current trunk. No need to go looking up the version number of the fork - Fossil will figure it out automatically. (2) After each commit in auto-sync mode, Fossil now does both a push and a pull. (Formerly it only did the push.) The extra pull means that if a fork occurred due to a race, it will be detected and a warning message will be printed. Both new features seem to work well for me. Thanks! -- 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] Unintentional fork/race condition
This is with regards to the problem described here: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html We are seeing on the order of 3-5 of these a year in our heaviest hit repos. While this may seem like no big deal the fact that it is so silent is quite disruptive. The problem is that a developer working intently on a problem may not notice for hours or even days that they are no longer actually working on the main thread of development. We added the fork detection code to the fossil wrapper which helps (we also see forks due to time lag on syncing between remote sites) but it is still a rather annoying problem. My question is can this be solved by wrapping the code that determines that we are at a leaf and the code that does the final commit with a BEGIN IMMEDIATE; ... END;? This increases the risk of leaving the db in a locked state so having a fossil command to unlock a database would be nice. In this same vein it would be very nice to be able to control the sqlite3 timeout. I'm fairly sure that a longer timeout would give us much better behaviour in our usage model. I have some scripting that can generate the forks and I'm willing to take a stab at making this change but wanted to hear from the list if this solution was worth trying. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Unintentional fork/race condition
On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland estifo...@gmail.com wrote: This is with regards to the problem described here: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html We are seeing on the order of 3-5 of these a year in our heaviest hit repos. While this may seem like no big deal the fact that it is so silent is quite disruptive. The problem is that a developer working intently on a problem may not notice for hours or even days that they are no longer actually working on the main thread of development. I contend that this points up issues with your development process, not with Fossil. If your developers do not notice that a fork has occurred for days, then they are doing heads down programming. They are not maintaining situational awareness. ( http://en.wikipedia.org/wiki/Situation_awareness) They are fixating on their own (small) problems and missing the big picture. This can lead dissatisfied customers and/or quality problems. Situational awareness is usually studied in dynamic environments that are safety critical, such as aviation and surgery. Loss of situational awareness is a leading cause of airplane crashes and medical errors. Loss of situational awareness is sometimes referred to as tunnel vision. The person fixates on one tiny aspect of the problem and ignores the much large crisis unfolding around him. Eastern Airlines flight 401 ( http://en.wikipedia.org/wiki/Eastern_Air_Lines_Flight_401) is a classic example of this: All three pilots of an L-1011 where working intently on a malfunctioning indicator light to the point that none of them noticed that the plane was losing altitude until seconds before it crashed in the Florida Everglades. Though usually studied in safety critical environments, situational awareness is applicable in any complex and dynamic problem environment, such as a developing advanced software. When you tell me that your developers are intently working on one small aspect of the problem, to the point of not noticing for several days that the trunk as forked - that tells me that there are likely other far more serious problems that they are also not noticing. The fork is easily fixed with a merge. The other more serious problems might not have such an easy fix. And they might go undetected until your customer stumbles over them. So, I would use the observation that forks are going undetected as a symptom of more serious process problems in your organization, and encourage you to seek ways of getting your developers to spend more time heads up and looking at the big picture. (Did you notice - situational awareness is kind of a big issue with me. Fossil is my effort at building a DVCS that does a better job of promoting situational awareness that the other popular VCSes out there. I'm constantly looking for ways to enhance Fossil to promote better situational awareness. Suggestions are welcomed.) Curious response. Did you intend to be insulting? I'm working with a bunch of very smart people who are very reluctantly learning a new tool and a different way of doing things and forks are very confusing when they happen in a scenario where they seemingly should not. We are not operating in a disconnected fashion here. Fossil falls somewhat short in the support of people who like to get their job done at the command line (about 80% of users on my team). Distilling from the fossil timeline command that there is a fork and how to fix it is not easy. It is very tiresome to have to go back to the ui to ensure that a fork hasn't magically appeared. Anyhow, I misunderstood the exact nature of the cause. I assumed that the race condition lay within the users fossil process between the time the db query that checked for leaf and the insertion of the new checkin data in to the db. That is of course incorrect. The actual cause is that the central database is free to receive a commit via sync after having just done a sync that informs the users fossil process that it is fine to commit. Something like the following: User1 User2central sync leafcheck sync commit leafcheck synccommit receives delta from user1 just fine sync receives delta from user2 and now a fork exists As you point out below that is very difficult if not impossible to fix. What I think would alleviate this issue would be a check for fork creation at the end of the final sync. If a fork is found notify the user so it can be dealt with before confusion is created. Just to illustrate, I think monotone deals rather nicely with the natural but annoying creation of forks. The user is informed immediately the fork occurs. Then the user only has to issue mtn merge and it does the easy and obvious merge. With fossil I have to poll the ui to ensure I don't have a fork, if I do have
Re: [fossil-users] Fossil vs. Git/Mercurial/etc.?
On Mon, Jan 7, 2013 at 4:32 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. This is exactly what I would like to see. Literally a mechanism to mark branches hidden where the markers are propagated on sync is all it would take. A .fossil-settings/hidden-branches file might be a good way to achieve this. from my previous post I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. = ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP SIGNATURE- ___ 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 8:20 AM, Lluís Batlle i Rossell vi...@viric.namewrote: (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'm one of those losers who uses fossil as a sort of backup work area sync tool in addition to a pure SCM. Now I don't personally feel the label loser applies to me but I'm using it here because repeatedly now on this list, intentional or accidentally, folks are using words that leave the impression that people who use fossil this way are, well, losers. Judging others in this way is not constructive IHMO. Perhaps instead try to understand why people are compelled to do this wrong behavior and perhaps enhance the tool(s) to make it unnecessary. Rebase exists because it meets a real need. The question is, can that need be met in a more elegant way with fossil? I work on several projects that are spread out over different machines and are not always accessible to me from all locations where I work. I often (yes, often) have work in progress that is far from polished yet if I don't check it in I have no easy way to continue working later from a different location. The pragmatic solution for me is to check in the current state of the code regardless of whether it is polished or not. I even (horrors) occasionally check in stuff that won't compile. I could use private branches to keep this clean but that adds another thing to remember and manage to my already overfilled plate and I've found it very easy to accidentally lose work with private branches. What I would like is a way to mark branches as hidden. A hidden branch does not show up on the timeline. In the UI there would be a show hidden branches button but by default they would not show. I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. Just my $0.02. Cheers and seasons greetings to all fossilers :) 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
Re: [fossil-users] Fossil scalability
Some time ago I did experiments with large numbers of commits and large amounts of data and I thought the fossil performance was quite acceptable. I did see things slow down but I don't recall it being as dramatic as what you are describing. How does your replay script work? Are you overlapping the subversion repo with the fossil one and doing an svn update so that fossil only sees the files touched that actually changed? If all files get touched in the repo that may slow things down unnecessarily. My method for doing what you are doing was to use rsync with appropriate ignores in a flow something like this: In svn repo: svn update rsync -av --delete [some excludes here] ./ /path/to/fossil/repo/ then in fossil repo: fsl addremove fsl commit This flow ensured that only actual changes were seen by fossil. I.e. unchanged files remain untouched. My results: Note: This scenario is very unrealistic in that every file has every line changed hundreds of times which creates thousands of tiny deltas that are time consuming to transfer. Repository size 704 MB Number of artifacts (objects stored) 234078 Number of check-ins 140119 Number of files 239 Data size (files in check out area) 178 MB Step Time (s) Comment Clone 94.609 Higher than would like, happens only once and can always fall back to copy + sync (8 secs) Copy + sync 7.690 Equivalent to clone Sync (no changes) 1.630 Update (no change, no sync) 0.004 Autosync turned off Open 7.060 Checkin (move one line in one file) 5.440 Autosync turned off Sync (one change) 2.500 Revert (all files touched) 6.360 On Fri, Dec 21, 2012 at 4:30 AM, Stefan Bellon sbel...@sbellon.de wrote: Hi! Previously I haven't used Fossil for very large repositories. But I like its concept and I am thinking about migrating our 15 years of history in four parallel Subversion repositories into one Fossil repository. I wrote a script to replay the commits from Subversion (at the moment just trunk) into Fossil and I am wondering whether I will end up with some usable state or not. In total, the Subversion repositories hold over 45000 revisions. The first 5000 revisions were converted in a quite acceptable time. But then things started to slow down. At the moment (at revision 8150) one Fossil commit takes around half a minute. I'm not sure whether the time is spend in the file system trying to find out which files (of the over 1 ones) to commit or in the real database operations of Fossil. However, I cannot imagine that it's the file system, because the same workspace is used daily to do Subversion commits which work instantaneously. So, is this some database inefficiency that can be solved via some regular optimize command? Or is this just the point where Fossil is not that scalable like other VCS? Just for reference, here's what Fossil's stats page of the current repository state (the conversion is still running) is saying: Repository Size:151875584 bytes (151.9MB) Number Of Artifacts:41671 (stored as 10572 full text and 31099 delta blobs) Uncompressed Artifact Size: 69607 bytes average, 31742157 bytes max, 2900554618 bytes (2.9GB) total Compression Ratio: 19:1 Number Of Check-ins:8150 Number Of Files:11667 Number Of Wiki Pages: 0 Number Of Tickets: 0 Duration Of Project:5649 days or approximately 15.86 years. Project ID: ad001d59eb3892b9dfad405a2bd5a752a04ef448 Server ID: 61c45d1915244bd9ff087951c9f5c6d59819d350 Fossil Version: 1.24 2012-10-22 12:48:04 [8d758d3715] (gcc-4.3.3 20081214 for GNAT Pro 6.2.2 (20090612)) SQLite Version: 2012-10-09 01:39:25 [01dc032b5b] (3.7.15) Database Stats: 148316 pages, 1024 bytes/page, 251 free pages, UTF-8, delete mode I'm looking forward to hearing your experience with projects of that size. Greetings, Stefan -- Stefan Bellon ___ 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] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin c...@apotheon.net wrote: On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. I don't think that's all there is to it. It isn't really fair to those who prefer automation of the full set of rm tasks to suggest they necessarily lack a sense of the idea, or to those who oppose that automation to suggest they lack a sense of pragmatism. I think that the two sides of this discussion are more sophisticated and complex than that, with several different types of argument being possible and presented on each side. The major argument types I have seen so far are: for rm automation| against rm automation --|-- idealist (Unix way) | idealists (airbags way) pragamtists (POLS way) | pragmatists (backward compat) trolls (haven't noticed any) | trolls (NIH and you're dumb) If you know of any trollish argument forms on the pro-automation side, please feel free to point them out. I may be suffering some confirmation bias in this case. Anyway, my explanations of the various arguments, as I have noticed them, follow. * Unix way idealists: When you tell it to do something, it damned well does it. * airbags way idealists: When you tell it to do something that might be accidentally applied in an unintentionally destructive manner by an incautious user, it should second-guess your intentions and try to convince you to do things differently, on the assumption that is not what you wanted. * POLS pragmatists: When you issue a command that seems like it should perform a given task, you expect it to perform the whole task, and not only part of it. Tool design should account for that. * backward compat pragmatists: This is how it has been done so far, establishing a set of expectations particular to long-time users and the automation scripts they have written that rely on the behavior in question. We should not change the tool's behavior to violate those ingrained expectations because there may be backward incompatibility problems. * NIH trolls: You're trying to turn Fossil into Git! Stop it! * you're dumb trolls: Obviously you are all too stupid to understand the benefits of keeping things the way they are. You are wrong because you are stupid; you are stupid because you disagree with me. If we could eliminate those troll category participants in the discussion, I think we would get a lot further in sorting this out. Nice analysis Chad! My sincere apologies to anyone insulted by my overly simplistic and arguably unfair comment :) I still want one of these two: Preferred behavior: remove file silently from disk iff the file is controlled and unchanged or if forced with -f. Issue a warning if the file was not removed. Also works for me: don't remove files unless forced with -f. With force all removals on disk happen without any notice. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What is missing is a way to register the fork with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real fork and not some random URL and then make the forks (with description?) browseable on a Forks page. The final piece of the puzzle would be the mechanism to pull only a single branch from a remote repo. What are the technical challenges with that? Is it enough to query the db for all the nodes on the branch and pull only that data or is there more to it? On Wed, Dec 12, 2012 at 3:27 PM, C. Thomas Stover c...@thomasstover.comwrote: blabbing I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil. In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. /blabbing For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google your project name. The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say hey folks check out fossil hack, it's up on a cloned repo at url abc. Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a public private branch in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, Dec 13, 2012 at 11:37 AM, C. Thomas Stover c...@thomasstover.comwrote: On Thu, 13 Dec 2012 09:27:03 -0700 Matt Welland estifo...@gmail.com wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What exactly does that do over a regular clone pull? Nothing really except that chiselapp will regularly pull from the parent. The point I was trying to make is that using chiselapp you can create public forks quite easily. What was missing was a mechanism to aggregate or document the forks so that people looking at a repo can find them. James Turner has indicated that he is interested in adding such a mechanism into chiselapp which I think will be great. I also think that such a feature would be very beneficial if integrated into fossil itself. If I use chiselapp or my own private server to clone the fossil-scm.comsite there is no record of the fork at the fossil-scm site. I personally think that having pointers to forks of the project would potentially stimulate more development activity. Certainly I'd like to have that for my own projects. Being able to pull in just a single branch from one of those forks would be icing on the cake. -- www.thomasstover.com ___ 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] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. Well put. I don't think so, actually. I've seen misuses (sort of) and misconceptions of SCMs here (on this list) and elsewhere. that happens. considering serious and sane use of SCM, I'm still perfectly sure that for the sole reason (repeated already way to often) that the by far most frequent use case of `fossil rm' and `fossil mv' will be a situation where the file system should reflect the change, the default behaviour should change. your previous suggestion in this direction did make perfect sense to me. the present one not so much. so I strongly opt for a default that does the real thing (yes!) of keeping repo and file system in sync (that's in my view what the SCM should always strive for. and to relegate different behaviour to the options, not the other way round. but, indeed, it is an interesting question why for heavens sake this issue does cause such a storm on this list? I don't get it. maybe it's too obvious to me that a default which forces me (and an estimate 99% of the other users) to type more than necessary -- which I don't like -- (and at the same time of running the risk of forgetting the additional actions and starting to mess things up) is no good while others have adjusted their mind to the current behaviour and don't want to change anything since it currently just works (tm). This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. When I saw that fossil was leaning more towards the idealistic side I created my fsl wrapper to make fossil workable in a real-world arena. Without my wrapper fossil would be unusable in our team. Maybe it is time for a more robust, written in C or similar, wrapper that adapts fossil for the pragmatists allowing the idealists to have their pristine usage model. Is this something that could be formally architected to be part of the fossil project? Basically it would be one tool with two faces. It is just a thought. My wrapper needs some work (I never did finish off the -r and -f for rm) but it works well enough for now. You can get it at https://chiselapp.com/user/kiatoa/repository/fsl/index and I very much welcome suggestions for improvement. Keep in mind that it is intended to make life easy for those on large teams working with large numbers of fossils (we have over two hundred fossils in use right now) in a pure Unix environment. I can tell you from own experience that it definitely does not help to convince svn users, e.g., that fossil is a interesting system (which it is). and yes: this alone sure is no argument. but it _is_ an argument if essentially all of the competitors (that I know of) go for the `scm rm/mv' act on the filesystem as well strategy for a reason. anywayt, I think everything has been said now more than once. I'll try to keep radio silence regarding this topic from know own (see whether I'm successful...). looking forward to the upcoming releases. I'll manage to use fossil in any case. j. So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty much convinced me at this point to keep the current behavior of fossil rm and fossil mv. But, should there be an opt-in option to also make the disk changes? Perhaps fossil rm abc.txt just removes abc.txt from configuration management, but fossil rm -f abc.txt also removes it from disk? And/or should there be a warning printed: File abc.txt removed from management but unchanged on disk just to give a heads-up to newcomers who expect different behavior? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Dec 11, 2012 at 3:08 PM, K k...@lightpowered.org wrote: I agree with Themba. I like that Fossil is a separate repo 'world' from my files. If this boundary is to be pierced, I think it should require passing in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this example representing sync. I would like some friendly tip text after rm/et al are ran, such as: You have removed file1.h, file1.c from repo foo, you may want to remove them from your working copy. Seems like a great way to remind, teach, and help all in-context and with minimal overhead. I thought that there was some degree of agreement that the destructive commands such as rm and mv would *require* -f (or some other switch) to do the same action on disk. If that is not the case then I share Themba's concern. This *will* cause grief. There is no need to make this configurable. My preference is to mirror the behavior of mecurial or git. Git's approach of checking that the file is unchanged from the head before doing the rm is safe and convenient. ^K on Dec 11, 2012, Themba Fletcher themba.fletc...@gmail.com wrote: Sorry to drag up an old thread, but I'm just checking back in after a lengthy absence. On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek no...@thewordnerd.info wrote: Weighing in on this, finally: It's interesting to me that everyone speculates that this *might* break things for some hypothetical person, and *might* bite someone, but has anyone here ever been bitten by it? It's the what if that bothers me. I use fossil as a safety net to manage an ungodly number of small maintenance projects, so I'm often not the original author of the project, and am almost never really comfortable with the code base I'm modifying. When I sync a code base to my machine and fossil add . --dotfiles I really appreciate the fact that I can trust fossil not to touch the disk if I accidentally add something that I don't want in there and have to remove it. In the presence of shabby and poorly maintained deploy/sync scripts, solo use of fossil, unknown modifications to the master since the last checkin, etc., the consequences of removing something from my local copy could be pretty embarrassing -- ie I could potentially blow away the only working copy of a new cusomer's web app. Not to say that I couldn't adjust to a new set of danger points, but that I do really appreciate fossil's current behavior. And is it not something that fossil revert could undo? Is it? What about: fossil add . (whoops) - fossil rm something fossil commit (take a phone call and forget it's fossil 2.0) sync up Now the files are gone locally, they're gone on the remote site, and fossil revert isn't going to help. This is obviously a workflow / deploy problem at its root, but it's a bit of sloppiness that fossil's current behavior forgives and the proposed behavior would not. I don't mind avoiding the change until a 2.0 release, but I worry about making it a setting, because I prescribe to the idea that settings add complexity both for users and developers. I agree about minimizing the extra overhead of a setting, but I come down personally on the side of it's working fine, so please don't touch it. Maybe my use case varies from the norm, but I don't do fossil rm all that often and, when I do, the extra overhead of having to do Up arrow, Ctrl-A, Alt-D, Return afterwards doesn't bother me at all. I like explicitly taking care of this as a second deliberate step. My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then just change it. There are plenty of settings already, please don't add another, especially for something that we're all speculating might affect someone who can't just revert for whatever reason. So, respectfully disagree. For me it's about not having to learn new rules about when fossil will touch my files and when it will not. Best Regards, Themba ___ 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] howto `grep' through old revisions
A grep though history would be a very useful functionality, There have been many times I'd have used it. Using sqlite3 glob or like for the pattern match would be more than adequate. If you need a regex just use the glob to select for the lowest common denominator and then pipe though egrep with the more complex regex to filter for exactly what you want. On Sat, Nov 24, 2012 at 7:35 AM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Sat, 24 Nov 2012 15:21:54 +0100, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff veedeeh...@googlemail.com **wrote: On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell vi...@viric.name wrote: 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? should stop at first hit by default but allow going through complete history optionally. I feel the `hg' people did it essentially right regarding this question: 8--- hg grep [OPTION]... PATTERN [FILE]... search for a pattern in specified files and revisions Search revisions of files for a regular expression. This command behaves differently than Unix grep. It only accepts Python/Perl regexps. It searches repository history, not the working directory. It always prints the revision number in which a match appears. By default, grep only prints output for the first revision of a file in which it finds a match. To get it to print every revision that contains a change in match status (- for a match that becomes a non-match, or + for a non-match that becomes a match), use the --all flag. Returns 0 if a match is found, 1 otherwise. options: -0 --print0 end fields with NUL --all print all revisions that match -a --texttreat all files as text -f --follow follow changeset history, or file history across copies and renames -i --ignore-case ignore case when matching -l --files-with-matches print only filenames and revisions that match -n --line-number print matching line numbers -r --rev REV [+] only search files changed within revision range -u --userlist the author (long with -v) -d --datelist the date (short with -q) -I --include PATTERN [+] include names matching the given patterns -X --exclude PATTERN [+] exclude names matching the given patterns --mq operate on patch repository [+] marked option can be specified multiple times 8--- this of course is already quite elaborate and thus not a proposal to do the same... but the default behaviour (stop at first hit) is good, the flags `l', `r' important, `u', `d', `i' sensible in my view. One big problem here is that the user will doubtless expect to have full Perl regular expressions. That will mean another compile-time dependency. no, no, heaven forbid. I didn't mean that. I have in mind more modest functionality. for me, at least, I would nearly be happy with fixed string patterns and glob patterns like something*other (or the regex equivalent something.*other) And maybe also a run-time dependency if a shared library is used (as most distribution packages managers will likely
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Nov 20, 2012 at 6:45 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff veedeeh...@googlemail.com wrote: I already stumbled a couple of times over the fact that `fossil rm' and `fossil mv' only act on the repository but not on the check out, i.e. I always have to issue two commands in order to actually remove a file from the (future of) the project. obviously this is different from other VCSs but I'm missing the point why it is a good idea to decouple both actions (removal from tracking and actual removal). any enlightenment appreciated... right now I'd say it'd be better to keep the actions coupled. CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. How about starting a 2.0 development track that does not guarantee backwards compatibility in all regards? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** fossil-usershttp://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] fossil 1.24 not working via ssh
, so maybe it's not too important, but it indicates of course that there still is something fundamentally not OK. * and it does not at all work with tcsh as login shell on the remote machine (even if login is completely silent). in this case I get the error message tput: No value for $TERM and no -T specified TERM: Undefined variable. Fossil-4473a27f3b6e049e/fossil: ssh connection failed: [test1 probe-4f5d9ab4] so, seemingly `tcsh' users are out of luck anyway. questions: * maybe the (echo/flush) process has to be iterated one further time to make fossil happy with ubuntu's motd (after all it's not the least frequent linux distro)? * could fossil (or a debug version) not provide a (additional) hexdump (a la `hexdump -C' on linux) of the content of `zIn' instead of using `fossil_fatal(ssh connection failed: [%s], zIn);'? in this way one might be able to at least to recognize what exactly is coming in which might help in tracking down the source of the trouble: it need not be printable characters coming over the ssh connection after all. j. On Sun, 11 Nov 2012 23:44:31 +0100, Richard Hipp d...@sqlite.org wrote: On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland estifo...@gmail.com wrote: I'll top-post an answer to this one as this thread has wandered and gotten very long, so who knows who is still following :) I made a simple tweak to the ssh code that gets ssh working for me on Ubuntu and may solve some of the login shell related problems that have been reported with respect to ssh: http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=**http://www.kiatoa.com/cgi-bin/**fossils/fossil/fdiff?v1=** 935bc0a983135b26v2=61f9ddf1e2c8bbb0http://www.** kiatoa.com/cgi-bin/fossils/**fossil/fdiff?v1=**935bc0a983135b26v2=** 61f9ddf1e2c8bbb0http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0 Not exactly the same patch, but something quite similar has been checked in at http://www.fossil-scm.org/fossil/info/4473a27f3bhttp://www.fossil-scm.org/**fossil/info/4473a27f3b http://**www.fossil-scm.org/fossil/**info/4473a27f3bhttp://www.fossil-scm.org/fossil/info/4473a27f3b- please try it out and let me know if it clears any outstanding problems, or if I missed some obvious benefit of Matt's patch in my refactoring. Joerg iasked if this will make it into a future release. Can Richard or one of the developers take a look at the change and comment? Note that unfortunately this does not fix the issues I'm having with fsecure ssh but I hope it gets us one step closer. Thanks, Matt -=- On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland estifo...@gmail.com wrote: On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff veedeeh...@googlemail.com**wrote: On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com wrote: sshfs is cool but in a corporate environment it can't always be used. For example fuse is not installed for end users on the servers I have access to. I would also be very wary of sshfs and multi-user access. Sqlite3 locking on NFS doesn't always work well, I imagine that locking issues on sshfs it doesn't? in which way? and are the mentioned problems restricted to NFS or other file systems (zfs, qfs, ...) as well? do you mean that a 'central' repository could be harmed if two users try to push at the same time (and would corruption propagate to the users' local repositories later on)? I do hope not so... I should have qualified that with the detail that historically NFS locking has been reported as an issue by others but I myself have not seen it. What I have seen in using sqlite3 and fossil very heavily on NFS is users using kill -9 right off the bat rather than first trying with just kill. The lock gets stuck set and only dumping the sqlite db to text and recreating it seems to clear the lock (not sure but maybe sometimes copying to a new file and moving back will clear the lock). I've seen a corrupted db once or maybe twice but never been clear that it was caused by concurrent access on NFS or not. Thankfully it is fossil and recovery is a cp away. Quite some time ago I did limited testing of concurrent access to an sqlite3 db on AFS and GFS and it seemed to work fine. The AFS test was very slow but that could well be due to my being clueless on how to correctly tune AFS itself. When you say zfs do you mean using the NFS export functionality of zfs? yes I've never tested that and it would be very interesting to know how well it works. not yet possible here, but we'll probably migrate to zfs in the not too far future. My personal opinion is that fossil works great over NFS but would caution anyone trying it to test thoroughly before trusting it. could well
Re: [fossil-users] fossil 1.24 not working via ssh
sshfs is cool but in a corporate environment it can't always be used. For example fuse is not installed for end users on the servers I have access to. I would also be very wary of sshfs and multi-user access. Sqlite3 locking on NFS doesn't always work well, I imagine that locking issues on sshfs could well be worse. sshfs is an excellent work-around for an expert user but not a replacement for the feature of ssh transport. On Sun, Nov 11, 2012 at 2:01 AM, Ramon Ribó ram...@compassis.com wrote: Sshfs didn't fix the problems that I was having with fossil+ssh, or at least only did so partially. Why not? In what sshfs failed to give you the equivalent functionality than a remote access to a fossil database through ssh? 2012/11/11 Timothy Beyer bey...@fastmail.net At Sat, 10 Nov 2012 22:31:57 +0100, j. van den hoff wrote: thanks for responding. I managed to solve my problem in the meantime (see my previous mail in this thread), but I'll make a memo of sshfs and have a look at it. joerg Sshfs didn't fix the problems that I was having with fossil+ssh, or at least only did so partially. Though, the problems that I was having with ssh were different. What I'd recommend doing is tunneling http or https through ssh, and host all of your fossil repositories on the host computer on your web server of choice via cgi. I do that with lighttpd, and it works flawlessly. Tim ___ 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 1.24 not working via ssh
I'll top-post an answer to this one as this thread has wandered and gotten
very long, so who knows who is still following :)
I made a simple tweak to the ssh code that gets ssh working for me on
Ubuntu and may solve some of the login shell related problems that have
been reported with respect to ssh:
http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0
Joerg iasked if this will make it into a future release. Can Richard or one
of the developers take a look at the change and comment?
Note that unfortunately this does not fix the issues I'm having with
fsecure ssh but I hope it gets us one step closer.
Thanks,
Matt
-=-
On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland estifo...@gmail.com
wrote:
On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff
veedeeh...@googlemail.com**wrote:
On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com
wrote:
sshfs is cool but in a corporate environment it can't always be used.
For
example fuse is not installed for end users on the servers I have access
to.
I would also be very wary of sshfs and multi-user access. Sqlite3
locking
on NFS doesn't always work well, I imagine that locking issues on sshfs
it doesn't? in which way? and are the mentioned problems restricted to
NFS
or other file systems (zfs, qfs, ...) as well?
do you mean that a 'central' repository could be harmed if two users try
to push at the same time (and would corruption propagate to the users'
local repositories later on)? I do hope not so...
I should have qualified that with the detail that historically NFS locking
has been reported as an issue by others but I myself have not seen it.
What
I have seen in using sqlite3 and fossil very heavily on NFS is users using
kill -9 right off the bat rather than first trying with just kill. The
lock
gets stuck set and only dumping the sqlite db to text and recreating it
seems to clear the lock (not sure but maybe sometimes copying to a new
file
and moving back will clear the lock).
I've seen a corrupted db once or maybe twice but never been clear that it
was caused by concurrent access on NFS or not. Thankfully it is fossil and
recovery is a cp away.
Quite some time ago I did limited testing of concurrent access to an
sqlite3 db on AFS and GFS and it seemed to work fine. The AFS test was
very
slow but that could well be due to my being clueless on how to correctly
tune AFS itself.
When you say zfs do you mean using the NFS export functionality of zfs?
yes
I've never tested that and it would be very interesting to know how well
it
works.
not yet possible here, but we'll probably migrate to zfs in the not too
far future.
My personal opinion is that fossil works great over NFS but would caution
anyone trying it to test thoroughly before trusting it.
could well be worse.
sshfs is an excellent work-around for an expert user but not a
replacement
for the feature of ssh transport.
yes I would love to see a stable solution not suffering from interference
of terminal output (there are people out there loving the good old
`fortune' as part of their login script...).
btw: why could fossil not simply(?) filter a reasonable amount of
terminal
output for the occurrence of a sufficiently strong magic pattern
indicating
that the noise has passed by and fossil can go to work? right now
putting
`echo ' (sending a single blank) suffices to let the transfer fail. my
understanding is that fossil _does_ send something like `echo test' (is
this true). all unexpected output to tty from the login scripts would
come
_before_ that so why not test for receiving the expected text ('test'
just
being not unique/strong enough) at the end of whatever is send (up to a
reasonable length)? is this a stupid idea?
I thought of trying that some time ago but never got around to it.
Inspired
by your comment I gave a similar approach a quick try and for the first
time I saw ssh work on my home linux box!!!
All I did was read and discard any junk on the line before sending the
echo
test:
http://www.kiatoa.com/cgi-bin/**fossils/fossil/fdiff?v1=**
935bc0a983135b26v2=**61f9ddf1e2c8bbb0http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0
===without==
rm: cannot remove `*': No such file or directory
make: Nothing to be done for `all'.
ssh matt@xena
Pseudo-terminal will not be allocated because stdin is not a terminal.
../fossil: ssh connection failed: [Welcome to Ubuntu 12.04.1 LTS
(GNU/Linux
3.2.0-32-generic-pae i686)
* Documentation: https://help.ubuntu.com/
0 packages can be updated.
0 updates are security updates.
test]
==with**===
fossil/junk$ rm *;(cd ..;make) ../fossil clone
ssh://matt@xena//home/matt/**fossils/fossil.fossil
fossil.fossil
make: Nothing to be done
Re: [fossil-users] fossil 1.24 not working via ssh
On Sun, Nov 11, 2012 at 3:44 PM, Richard Hipp d...@sqlite.org wrote:
On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland estifo...@gmail.com wrote:
I'll top-post an answer to this one as this thread has wandered and
gotten very long, so who knows who is still following :)
I made a simple tweak to the ssh code that gets ssh working for me on
Ubuntu and may solve some of the login shell related problems that have
been reported with respect to ssh:
http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0
Not exactly the same patch, but something quite similar has been checked
in at http://www.fossil-scm.org/fossil/info/4473a27f3b - please try it
out and let me know if it clears any outstanding problems, or if I missed
some obvious benefit of Matt's patch in my refactoring.
It seems not to work in my situation with the sending of test1. I'm not
sure why.
= I get the following
fossil/junk$ ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil
fossil.fossil
ssh matt@xena
Pseudo-terminal will not be allocated because stdin is not a terminal.
../fossil: ssh connection failed: [test1]
Joerg iasked if this will make it into a future release. Can Richard or
one of the developers take a look at the change and comment?
Note that unfortunately this does not fix the issues I'm having with
fsecure ssh but I hope it gets us one step closer.
Thanks,
Matt
-=-
On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff veedeeh...@googlemail.com
wrote:
On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland estifo...@gmail.com
wrote:
On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff
veedeeh...@googlemail.com**wrote:
On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com
wrote:
sshfs is cool but in a corporate environment it can't always be used.
For
example fuse is not installed for end users on the servers I have
access
to.
I would also be very wary of sshfs and multi-user access. Sqlite3
locking
on NFS doesn't always work well, I imagine that locking issues on
sshfs
it doesn't? in which way? and are the mentioned problems restricted to
NFS
or other file systems (zfs, qfs, ...) as well?
do you mean that a 'central' repository could be harmed if two users
try
to push at the same time (and would corruption propagate to the users'
local repositories later on)? I do hope not so...
I should have qualified that with the detail that historically NFS
locking
has been reported as an issue by others but I myself have not seen it.
What
I have seen in using sqlite3 and fossil very heavily on NFS is users
using
kill -9 right off the bat rather than first trying with just kill. The
lock
gets stuck set and only dumping the sqlite db to text and recreating
it
seems to clear the lock (not sure but maybe sometimes copying to a new
file
and moving back will clear the lock).
I've seen a corrupted db once or maybe twice but never been clear that
it
was caused by concurrent access on NFS or not. Thankfully it is fossil
and
recovery is a cp away.
Quite some time ago I did limited testing of concurrent access to an
sqlite3 db on AFS and GFS and it seemed to work fine. The AFS test was
very
slow but that could well be due to my being clueless on how to correctly
tune AFS itself.
When you say zfs do you mean using the NFS export functionality of zfs?
yes
I've never tested that and it would be very interesting to know how
well it
works.
not yet possible here, but we'll probably migrate to zfs in the not too
far future.
My personal opinion is that fossil works great over NFS but would
caution
anyone trying it to test thoroughly before trusting it.
could well be worse.
sshfs is an excellent work-around for an expert user but not a
replacement
for the feature of ssh transport.
yes I would love to see a stable solution not suffering from
interference
of terminal output (there are people out there loving the good old
`fortune' as part of their login script...).
btw: why could fossil not simply(?) filter a reasonable amount of
terminal
output for the occurrence of a sufficiently strong magic pattern
indicating
that the noise has passed by and fossil can go to work? right now
putting
`echo ' (sending a single blank) suffices to let the transfer fail.
my
understanding is that fossil _does_ send something like `echo test' (is
this true). all unexpected output to tty from the login scripts would
come
_before_ that so why not test for receiving the expected text ('test'
just
being not unique/strong enough) at the end of whatever is send (up to a
reasonable length)? is this a stupid idea?
I thought of trying that some time ago but never got around to it.
Inspired
by your comment I gave a similar approach a quick try and for the first
time I saw ssh work on my home linux box!!!
All I did was read and discard any junk on the line before
Re: [fossil-users] fossil 1.24 not working via ssh
Comparison of your fix vs. my hack below. I suspect that blindly clearing out the buffer of any line noise before sending anything to the remote end will work better but I have no logic or solid arguments to back up that assertion. = matt@xena:~/data/fossil/junk$ fsl info project-name: Fossil repository: /home/matt/fossils/fossil.fossil local-root: /home/matt/data/fossil/ project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 checkout: 4473a27f3b6e049e3c162e440e0e4c87daf9570c 2012-11-11 22:42:50 UTC parent: 8c7faee6c5fac25b8456e96070ce068400d1d7e1 2012-11-11 17:59:42 UTC tags: trunk comment: Further attempts to help the ssh sync protocol move past noisy motd comments and other extraneous login text, synchronize with the remote end, and start exchanging messages successfully. (user: drh) matt@xena:~/data/fossil/junk$ rm -f fossil*;(cd ..;make) ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil fossil.fossil make: Nothing to be done for `all'. ssh matt@xena Pseudo-terminal will not be allocated because stdin is not a terminal. ../fossil: ssh connection failed: [test1] = matt@xena:~/data/fossil/junk$ rm -f fossil*;(cd ..;make make.log) ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil fossil.fossil ssh matt@xena Pseudo-terminal will not be allocated because stdin is not a terminal. Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 5004225 13950 1751 5238 Sent: 71 2 0 0 Received: 5032480 9827 1742 3132 Sent: 57 93 0 0 Received: 5012028 9872 1137 3806 Sent: 57 1 0 0 Received: 4422156 3069367 1169 Total network traffic: 1035 bytes sent, 19471761 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: 3e5f8ed7b0eed8a144fa4b07b4b34cc6c374d20c admin-user: matt (password is 40faae) On Sun, Nov 11, 2012 at 6:09 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Nov 11, 2012 at 7:10 PM, Matt Welland estifo...@gmail.com wrote: On Sun, Nov 11, 2012 at 3:44 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Nov 11, 2012 at 5:11 PM, Matt Welland estifo...@gmail.comwrote: I'll top-post an answer to this one as this thread has wandered and gotten very long, so who knows who is still following :) I made a simple tweak to the ssh code that gets ssh working for me on Ubuntu and may solve some of the login shell related problems that have been reported with respect to ssh: http://www.kiatoa.com/cgi-bin/fossils/fossil/fdiff?v1=935bc0a983135b26v2=61f9ddf1e2c8bbb0 Not exactly the same patch, but something quite similar has been checked in at http://www.fossil-scm.org/fossil/info/4473a27f3b - please try it out and let me know if it clears any outstanding problems, or if I missed some obvious benefit of Matt's patch in my refactoring. It seems not to work in my situation with the sending of test1. I'm not sure why. The trunk changes works here. And I don't see how it is materially different from your patch. Am I overlooking something? = I get the following fossil/junk$ ../fossil clone ssh://matt@xena//home/matt/fossils/fossil.fossil fossil.fossil ssh matt@xena Pseudo-terminal will not be allocated because stdin is not a terminal. ../fossil: ssh connection failed: [test1] Joerg iasked if this will make it into a future release. Can Richard or one of the developers take a look at the change and comment? Note that unfortunately this does not fix the issues I'm having with fsecure ssh but I hope it gets us one step closer. Thanks, Matt -=- On Sun, Nov 11, 2012 at 1:53 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Sun, 11 Nov 2012 19:35:25 +0100, Matt Welland estifo...@gmail.com wrote: On Sun, Nov 11, 2012 at 2:56 AM, j. van den hoff veedeeh...@googlemail.com**wrote: On Sun, 11 Nov 2012 10:39:27 +0100, Matt Welland estifo...@gmail.com wrote: sshfs is cool but in a corporate environment it can't always be used. For example fuse is not installed for end users on the servers I have access to. I would also be very wary of sshfs and multi-user access. Sqlite3 locking on NFS doesn't always work well, I imagine that locking issues on sshfs it doesn't? in which way? and are the mentioned problems restricted to NFS or other file systems (zfs, qfs, ...) as well? do you mean that a 'central' repository could be harmed if two users try to push at the same time (and would corruption propagate to the users' local repositories later on)? I do hope not so... I should
[fossil-users] Fossil gdiff fails on system where /var/tmp is a symlink
Reported a while ago, any progress or work-around? Fossil still has a problem with /var/tmp. May be related to it being a symlink? bash-3.00$ ~/bin/fossil gdiff --to d69a --from 4509 Index: dashboard.scm == /nfs/site/home/mrwellan/bin/fossil: unable to create directory /var/tmp == bash-3.00$ fossil test-canonical-name / /var /var/tmp [/] - [/] file_size = 4096 file_mtime = 135459 file_isfile = 0 file_isfile_or_link = 0 file_islink = 0 file_isexe = 0 file_isdir = 1 [/var] - [/var] file_size = 4096 file_mtime = 135459 file_isfile = 0 file_isfile_or_link = 0 file_islink = 0 file_isexe = 0 file_isdir = 1 [/var/tmp] - [/var/tmp] file_size = 4096 file_mtime = 1352224050 file_isfile = 0 file_isfile_or_link = 0 file_islink = 0 file_isexe = 0 file_isdir = 1 === bash-3.00$ ls -l /var total 96 ... drwxr-xr-x 13 root root 4096 2010-10-08 20:54 spool lrwxrwxrwx 1 root root 12 2010-10-08 20:54 tmp - /tmp/var.tmp drw--- 4 root root 4096 2010-10-08 20:54 tmp.old ... ___ fossil-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 gdiff fails on system where /var/tmp is a symlink
Yes, that fixed it. Thanks!
On Tue, Nov 6, 2012 at 11:02 AM, Richard Hipp d...@sqlite.org wrote:
On Tue, Nov 6, 2012 at 12:53 PM, Matt Welland estifo...@gmail.com wrote:
Reported a while ago, any progress or work-around?
Does the following change help?
Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -800,11 +800,11 @@
** The if stops us from trying to create a directory of a drive
letter
** C: in this example.
*/
if( !(i==2 zName[1]==':') ){
#endif
- if( file_mkdir(zName, 1) ){
+ if( file_mkdir(zName, 1) file_isdir(zName)!=1 ){
fossil_fatal_recursive(unable to create directory %s,
zName);
return 0;
}
#if defined(_WIN32)
}
Fossil still has a problem with /var/tmp. May be related to it being a
symlink?
bash-3.00$ ~/bin/fossil gdiff --to d69a --from 4509
Index: dashboard.scm
==
/nfs/site/home/mrwellan/bin/fossil: unable to create directory /var/tmp
==
bash-3.00$ fossil test-canonical-name / /var /var/tmp
[/] - [/]
file_size = 4096
file_mtime = 135459
file_isfile = 0
file_isfile_or_link = 0
file_islink = 0
file_isexe = 0
file_isdir = 1
[/var] - [/var]
file_size = 4096
file_mtime = 135459
file_isfile = 0
file_isfile_or_link = 0
file_islink = 0
file_isexe = 0
file_isdir = 1
[/var/tmp] - [/var/tmp]
file_size = 4096
file_mtime = 1352224050
file_isfile = 0
file_isfile_or_link = 0
file_islink = 0
file_isexe = 0
file_isdir = 1
===
bash-3.00$ ls -l /var
total 96
...
drwxr-xr-x 13 root root 4096 2010-10-08 20:54 spool
lrwxrwxrwx 1 root root 12 2010-10-08 20:54 tmp - /tmp/var.tmp
drw--- 4 root root 4096 2010-10-08 20:54 tmp.old
...
___
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] Rebase is NOT fundamentally incompatible with Fossil
I like the idea of cherry picking to a new branch. This would have nicely solved a few problems I've faced. I suppose you can kind of do this now using fossil cherrypick and manually creating the new branch but the equivalency to the original edits is not preserved and merging back into a stream with the original edits will probably not work correctly in many cases. I'd give two thumbs up to this idea. On Tue, Aug 14, 2012 at 2:16 PM, Nico Williams n...@cryptonector.comwrote: Provocative Subject: line, I know. But it's true, git-like rebase is not incompatible with Fossil's principles *provided* that the result of a rebase is a new branch, or provided that the branch being affected has no children (i.e., that it's a private branch). I use git a lot, and I like it. I also like the ideas behind Fossil. I'm only really missing git cherry-pick and git rebase (which is based, really, on cherry-pick). Why rebase? I'd like to give you three example use cases where git cherry-pick and git rebase have been important to me. I hope that there are Fossil-specific alternatives, but if not then I hope that these examples will be useful to the Fossil community. Example #1: Rebasing commits in response to code reviews prior to upstream integration. Upstreams rarely ever want their canonical history polluted by a developer's typical missteps (typos, etcetera). See http://github.com:nicowilliams/krb5/branches, look for branches named kadm5_polic_exts*. Each one of these represents a rebase of another. That is, when I use git rebase I mostly do it in brand new branches so as to not be destructive of the original, even when all these branches are private as in this case. Each rebase was in response to code review comments. Some rebases I did in various sequences, first one to re-organize some commits (e.g., reorder, split, or squash them), then another to fix minor issues. Example #2: Cherry-picking from site-local feature branches onto site-local release branches. One SCM workflow I like involves maintaining sets of local patches to open source projects, with each patchset kept as local feature branches based on upstream release branches. To make a new site-local release from a new upstream release we first create a new site-local release branch for each site-local feature based on the new upstream release, cherry-pick/merge the given feature patches onto the new feature branches, test, then finally merge all the site-local feature branches onto a site-local release branch based on the new upstream release branch. git cherry-pick isn't essential here: git merge would suffice. But the cherry-pick concept allows more control over the merge metadata. Note that these site-local feature branches and site-local release branches are not always shared with the upstream (some hold patches that upstream does not want or which would be obviously of no interest to the upstream community), but they're not necessarily private in the sense of not being shared with other site-local repositories (e.g., developers'). Example #3: Intermediate upstreams (project gates). This example is very much based on how development was done at Sun Microsystems, and in all certainty still is at Oracle in groups acquired via the acquisition of Sun, and is how I do some development today for some customers. In this model we have upstream gates, project gates, and developer repositories. Developers branch off of project gates and push commits to the project gates. Project gates track upstream gates until the projects complete, at which point they push their changes upstream. You can surely see the problem though: as commits from multiple projects get pushed upstream each remaining downstream project gate has to rebase, and that breaks all their further downstream developers. Clearly this is broken. But there's a way to make this work, and we did this at Sun all the time: the rebases are done on new gates based on the old gates. In git this works as follows. First, the root upstream has a single canonical branch (master), the project gates are either branches off the canonical upstream branch, possibly in distinct repos, ditto the developer gates. Second, the project gates rebase periodically, each time creating a *new* branch and closing the previous project gate branch to new commits. Third, developers periodically rebase their branches onto (think of git rebase --onto=...) the new, rebased project gates. At Sun periodically meant specifically that we had build schedules that resulted in build releases, at which point a snapshot branch was created of the upstream root. Thus the periodic rebasing for the project gates was scheduled and
Re: [fossil-users] How do I rebuild my fossil repo?
On Thu, Jul 5, 2012 at 9:22 AM, Cunningham, Robert rcunning...@nsmsurveillance.com wrote: I had started thinking along similar lines, and I just realized that git seems to be becoming a vital utility for Fossil. The export/import cycle appears to be useful in multiple scenarios encountered by Fossil users. There has also been much discussion about adding git-like features to Fossil. ** ** Would it be useful to think of Fossil becoming a git fork, where the core git functionality (at the capability level) is sandwiched between a low-level database and the high-level Fossil UI? I see the fast export as a last resort for tough problems. I never routinely go back and forth. If Fossil and git get any closer, they’ll be family. ** As others have pointed out there are some pretty substantial differences in philosophy and convergence seems unlikely. I would say appreciate each tool for it's unique qualities and use the one that is best for you. To attempt to straddle two worlds will probably be painful. I've done bridges between various SCM's in the past and would say that it just generally isn't worth the pain and risk. ** Thoughts? ** ** -BobC ** ** ** ** *From:* fossil-users-boun...@lists.fossil-scm.org [mailto: fossil-users-boun...@lists.fossil-scm.org] *On Behalf Of *Matt Welland *Sent:* Thursday, July 05, 2012 8:33 AM *To:* Fossil SCM user's discussion *Subject:* Re: [fossil-users] How do I rebuild my fossil repo? ** ** ** ** On Thu, Jul 5, 2012 at 1:02 AM, Stephan Beal sgb...@googlemail.com wrote: The only way i can think of is to dump/import the sql. Sorry for the brevity - typing on a phone on an over-full train. ** ** I think that dumping to a git fast export format and then writing scripts to manipulate the fast import data or importing to git, doing what needs to be done, then re-importing to fossil might be a good strategy for what you want. It won't help you with the tickets or other fossil specific data. I believe it is a loss-less process. I was able to slice and dice a large number of monotone db's into fossil db's using this approach. - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jul 5, 2012 7:52 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote:*** * ** ** On Thu, Jul 5, 2012 at 12:17 PM, altufa...@mail.com wrote: With help of some scripting and SQL, you can find all UUIDs for files that you want to remove and shun them. after that when you rebuild, your repo file will be shrunk. It is a bit effort though. ** ** ** ** Could somebody point out to the documentation of internal table structure and their relationship? ** ** - Original Message - From: Stephan Beal Sent: 07/05/12 09:15 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How do I rebuild my fossil repo? Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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 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] How do I rebuild my fossil repo?
On Thu, Jul 5, 2012 at 1:02 AM, Stephan Beal sgb...@googlemail.com wrote: The only way i can think of is to dump/import the sql. Sorry for the brevity - typing on a phone on an over-full train. I think that dumping to a git fast export format and then writing scripts to manipulate the fast import data or importing to git, doing what needs to be done, then re-importing to fossil might be a good strategy for what you want. It won't help you with the tickets or other fossil specific data. I believe it is a loss-less process. I was able to slice and dice a large number of monotone db's into fossil db's using this approach. - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jul 5, 2012 7:52 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: On Thu, Jul 5, 2012 at 12:17 PM, altufa...@mail.com wrote: With help of some scripting and SQL, you can find all UUIDs for files that you want to remove and shun them. after that when you rebuild, your repo file will be shrunk. It is a bit effort though. Could somebody point out to the documentation of internal table structure and their relationship? - Original Message - From: Stephan Beal Sent: 07/05/12 09:15 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How do I rebuild my fossil repo? Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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 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] Turning off change tracking for certain files
Just a general comment on this proposal To reiterate the solution provided by Mike, I think this problem can be easily solved by user methodology with no changes to fossil. If you have generated or user edited files create and check in templates. Add the appropriate targets to your make file to copy (and possibly modify) the template to the needed file if it does not exist. These special case files are going to be one more thing a new user has to learn and deal with and the ROI is very low. It will be hard to see the different status between a normally controlled file and the special file. An alternative would be to consider the git model where you have to mark files for commit. It is a general solution that does address this need. On Mon, Jul 2, 2012 at 6:55 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer m...@mired.org wrote: My solution has been to push things out to the build system. What gets stored in the repo is config.template. In this, the values for Another option might, depending on the system, be to include a local config file/make file/whatever. e.g. in Make it might look like: -include Makefile.$(USER) the - before include means don't fail if the file does not exist, and most devs have the same $(USER) on their dev machine(s). (And if they don't, a symlink can work as a crutch to link multiple names to one makefile.) For small teams, Makefile.$(USER) might even be checked in. The Ant build system allows one to include custom property files, so you could add local.config to your imports and you're all set. Developers which don't need it simply need to create a 0-byte copy locally. -- - 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
Re: [fossil-users] Fossil on Android or compiling with tcc?
Perhaps not relevant to Android but just in case it helps I run fossil on my n900 (arm based antiquated smart phone). I built using scratchbox, http://www.scratchbox.org. It was an almost zero effort compile. On Tue, Jun 19, 2012 at 11:16 AM, Mike Meyer m...@mired.org wrote: On Tue, 19 Jun 2012 18:07:58 +0200 Stephan Beal sgb...@googlemail.com wrote: Yesterday i got a tcc-based compiler for my tablet and i am curious if any of you have gotten fossil to compile (perhaps cross-compiling?) on (or for) Android? There's been some work done on cross-compiling. If you google for compile fossil for android, you'll turn up my patches/instructions for getting things to compile. I vaguely recall that someone managed to get it working properly, but that didn't turn up when I did the google search. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] send mail on checkin?
On Tue, Jun 5, 2012 at 11:39 AM, Jeremy Anderson jere...@gmail.com wrote: Something my team finds useful at work is a way to send checkin mail - an automated email that is fired off by our old SCM (or a companion process) to a specific email list address (which users can sub/unsub from to opt in/out) which describes the change (including the changelist number, the comments, and the files modified). Does fossil have anything like this that can be configured on one of the instances (e.g, in our topology, we have a single fossil server which runs Fossil as a service. everyone clones their individual developer repo's from it and syncs to it. this central Fossil instance would be the ideal entity to monitor changes from and to send email as a result). An alternative possibility for your consideration We thought we needed the same thing for our team, email notification on various events such as commit. Then we took a look at the rss capability of fossil and quickly realized that the rss feed is far superior to triggered emails. Same data, same granularity, much better management of the information, zero setup cost, zero maintenance of scripts etc. If your repo is at http://host.dom/fossils/myfossil then add http://host.dom/fossils/myfossil/timeline.rss to your rss reader (we are using outlook which seems to work fine). Thanks! -jer ___ 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] Newbie question about basics of using fossil
On Thu, May 31, 2012 at 7:21 AM, Andrew Stuart andrew.stu...@supercoders.com.au wrote: Hello all, I'm a complete newb with fossil and trying to grasp some basic concepts. I have an Ubuntu system that I am developing on. I want to ensure that various files that I modify are in Fossil SCM. There are source code files and also operating system configuration files. I use sudo to edit these files as most of the files are editable only by root. How do I use Fossil in this context? Where should I set up the fossil repository? In my unprivileged user home directory? How should I be handling the need to use sudo to access the various files that I work on? I suspect I'll be running into various permissions issues constantly? Would my workflow look something like this for example? 1: Create fossil repo in my home directory 2: Go to the location of a file I want to put in fossil 3: fossil open in this directory 4: fossil add the files I wish to put under scm Although I have read the quickstart guide it doesn't really nudge me in the right direction of how to actually drive it in a practical manner, especially where I have to use sudo. From your email I gather that you have a mix of files to control, some are perhaps in /etc or some other system location and some are source files? Your recipe above would work if *all* the files to be controlled live under the location where you ran the fossil open command. However I suggest not attempting to directly control the system files. Instead copy the files to a working area where you do the fossil open then write a Makefile that has rules to put the files in place. E.g. something like this: /etc/some/file.cfg : file.cfg sudo install file.cfg /etc/some/file.cfg thanks heaps. Andrew __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] losing history in private branch merge?
On Fri, May 25, 2012 at 9:10 AM, org.fossil-scm.fossil-us...@io7m.comwrote: On Fri, 25 May 2012 11:53:35 -0400 Richard Hipp d...@sqlite.org wrote: On Fri, May 25, 2012 at 11:42 AM, org.fossil-scm.fossil-us...@io7m.comwrote: Is it possible to avoid squashing all private commits into one? The branch is private. If all the individual commits where pushed out to the world, it wouldn't be private any more and the whole purpose of having a private branch would be defeated, no? That's one interpretation of private, yes. I took it to mean that the branch wouldn't be synced, or visible, on any remotes. I don't think that necessarily implies coalescing commits like that... If it's not possible, I can live with it, I'll just switch to only using public branches. It sounds like the request would be able to switch a branch from private to public. That seems like it would be a very powerful feature (assuming it is not already possible?). ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. ___ 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] fossil bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 3:11 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:34 PM, Matt Welland estifo...@gmail.com wrote: On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. In which case, the two files have nothing in common and the whole thing is one big merge conflict. Is that really helpful? Assuming that the work done in both files is important to the authors who wrote it I'd say yes. The solution for the auto-merge-with-conflict could be as simple as putting the contents of the one parent above the other with the usual merge markers. Creating an empty common ancestor file and the original and merge files would be helpful too as most folks probably rely on a gui merge tool which can handle this just fine. Currently it looks to the first person to commit as though their changes were discarded. The file is marked MERGED yet only contains content from the last person to add. Perhaps not something that will happen very often but the behavior is clearly wrong. Matt -=- ___ 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 -- 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] fossil bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 5:25 PM, Michael L. Barrow mlbar...@barrow.mewrote: Currently it looks to the first person to commit as though their changes were discarded. The file is marked MERGED yet only contains content from the last person to add. Perhaps not something that will happen very often but the behavior is clearly wrong. Unless I did something wrong while emulating the tests, the data is not discarded per se. One can move aside the new version of the file, update to get the old version and then manually do the merge. Was that not your experience? Yes, of course the old data is available and recovery is not hard. The behavior is still far from ideal in my opinion. You don't drop lines from a file with no visible hint to the user what data may be missing. I copied the script and ran it with some additional scenarios to see what would happen: 1. as test case was provided by Justin result: CONFLICT no hint inside the file of conflicting data. no launch of gui merge tool may or may not be easy to merge with gui merge tool 2. with all lines the same but for one result: CONFLICT no hint inside the file of conflicting data no launch of gui merge very easy to merge with a gui merge tool 3. with one line added at end of file result: CONFLICT no hint inside the file of the potentially missing line no launch of gui merge gui tools automatically merge these correctly. 4. identical files result: CONFLICT no merge necessary Every one of these cases is not handled well by fossil and there is no hint that data was dropped from view. I think a new user will be very confused by what they see. The 1st and 2nd case should have the conflict markers and or launch the merge gui. The 3rd case should probably be automatically merged with no CONFLICT warning. The 4th case should NOT report CONFLICT. -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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 commands will not follow through managed symlink dirs
On Thu, May 17, 2012 at 5:02 PM, Gé Weijers g...@weijers.org wrote: Oops I sent this out before it was ready. Basically, you keep a list of device-inode pairs for each file while traversing the file system, which lets you detect duplicates. Ge' Can realpath or equivalent be used in fossil? If so it would be simpler. I think this scenario is not really the same as hard links. From man 3 realpath #include limits.h #include stdlib.h char *realpath(const char *path, char *resolved_path); DESCRIPTION realpath() expands all symbolic links and resolves references to /./, /../ and extra '/' characters in the null-terminated string named by path to produce a canonicalized absolute pathname. The resulting pathname is stored as a null-terminated string, up to a maximum of PATH_MAX bytes, in the buffer pointed to by resolved_path. The resulting path will have no symbolic link, /./ or /../ components. -- Gé ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil push doesn't show up on the server
I think this is a good illustration of how noisy output makes it hard for new users to see problems occurring. I would prefer to see most of the sync output suppressed unless a verbose switch is flipped. Most of the time people really only need to know that the sync succeeded or failed. At the very least make the error messages stand out more with an all upper case ERROR: prefix. On Mon, May 7, 2012 at 9:29 AM, James Turner ja...@calminferno.net wrote: On Mon, May 07, 2012 at 06:23:53PM +0200, Pascal J. Bourguignon wrote: What's wrong? What should I do to push my commits? Your answer is in the output of your failed fossil push: Error: not authorized to write -- James Turner ja...@calminferno.net ___ 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] SSH commands run as user nobody
Regarding ssh transport for fossil: I've been trying to get ssh to work with fsecure and on Linux (openssh) and I have never had any luck. If someone using fossil ssh for clone, sync etc. with different user(s) or different hosts at either end of the pipe could post their exact setup and settings I will try again as I really need this to work. On Mon, May 7, 2012 at 1:29 PM, Timothy Beyer bey...@fastmail.net wrote: At Mon, 7 May 2012 06:51:19 -0400, Martin Gagnon wrote: Have you update server side as well? Here is the output of fossil version on the server: This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC Here is the output of fossil version on the client: This is fossil version 1.22 [7fb59a67dc] 2012-05-05 13:53:37 UTC I just issued another fossil all rebuild on both the client and the server to make sure that I didn't miss anything. I am still getting the Error: not authorized to read error. First I tried just rebuilding on the client side, then trying the sync, which didn't work, giving the same error. Then I tried closing the repository on the client side, re-cloning under sshfs again, changing the remote-url (where it prompted me for the password as normally, then issuing the fossil sync command. Basically, it displays the Sent: packets as it should, then it gives the Error: not authorized to read, then it prints the received packets. In my testing, the sync never actually updated the repository until I gave nobody expanded permissions, in which the latest revisions were updated on the timeline command. Maybe the fix is in a branch other than trunk? Should I try another branch when installing from the fossil repository? Possibly unrelated: Maybe my issue is specific to FreeBSD? I am testing this under /bin/sh shell (I have my shell even changed to /bin/sh at the moment on the server side to ensure the proper behavior) because the ssh commands do not work under tcsh at all... Tim ___ 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] recent change: alt-root and its purpose?
On Mon, Apr 30, 2012 at 5:31 AM, Richard Hipp d...@sqlite.org wrote: On Mon, Apr 30, 2012 at 8:17 AM, Leo Razoumov slonik...@gmail.com wrote: On Sat, Apr 28, 2012 at 09:34, Richard Hipp d...@sqlite.org wrote: [snip] I think this means that every time one accesses a repository via cg-bin the repository updates the baseurl:... entry. This would make rsync based replication/backup scripts go nuts (they depend on timestamps and checksums). No. The entry is only updated if it does not previously exist or if the database file was changing for some other reason. Note that the database already gets updated every time somebody signs in. And Fossil uses the database as a cache in some circumstances, so already many if not most CGI accesses already write to the database file. This has been the case for ages. Note that rsync only transmits the differences between two files, so making small changes to one table is not going to seriously impact rsync performance. The www.fossil-scm.org website is backed up using rsync. And, really, fossil sync is a better backup of repositories than rsync anyhow. Ok, since the *only* time the fossil db is modified is on fossil open then the impact here is less than my first impression. The only request I have is that should the db being opened be read-only that a warning is issued and the open proceeds normally. This means that in those situations where it is needed to open a db that is read-only no extra steps are required but if someone mistakenly opens a read-only db then they get a nice big WARNING. Would it be better to have a configuration settings track-access (on/off) and track-ckout (on/off) to allow a user to selectively enable/disable new behavior according to his/her needs? --Leo-- -- 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] Idea: Close coupled usage model for fossil
The discussion on keeping the location of checkouts in the repo deb brought up an interesting thought. Observing the usage in our teams it is apparent that the distributed nature of fossil is more of a burden than a benefit 90% of the time but that remaining 10% of the time we very much appreciate the flexibility of distributed scm. One model of usage that fossil seems very close to being able to support is a centralized single db with optional distributed cloning where needed. You store the master repo on NFS group writeable with group sticky bit on the directory. All users open directly from that repo db. There is no sync and no local copies of the db. This makes fossil blazingly fast (try doing some fossil operations with sync turned off to see what I mean) and for a closely knit fast moving team seeing what others are doing in near real time is highly desirable. So far as I know there are only two things needed to make this usage model a reality. 1. Long timeout, multiple retries or a graceful exit with please try again in one minute on db access collisions. 2. User name handling on local access should respect the environment $USER and not the first entry in the users table. Note: NFS file locking seems very reliable and I use sqlite3 successfully with over a hundred processes spread over many machines by using long timeouts and few joins. Making this model work for teams of up to 10 or so people seems viable. So, is this feasible? Are there other gotcha's lurking in the design and implementation of fossil that make this a bad idea? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Update to fsl wrapper, detects and informs user if there are forks.
We've had several folks get very confused by the accidental creation of forks. The conversation goes something like this: DeveloperA: Go ahead and update, I've checked in change xyz DeveloperB: Ok (pause) I don't see it are you sure you checked it in ... and fifteen minutes later I get a call ... Matt, fossil is broken ... and I get to explain forks, how they happen and how to fix them :-) The problem is that forks can be silently created by disconnected operations and can lie hidden for some time. To mitigate this we added fork detection to the wrapper for the following operations: changes, status, update, timeline and co. matt@xena:~/data/fsl$ fsl stat WARNING!!! Fork detected on trunk, use fsl leaves and fsl merge to find and correct. repository: /home/matt/fossils/fsl.fossil local-root: /home/matt/data/fsl/ checkout: f6ef89b074d9ac02f00074b1bd03b0d52686306a 2012-05-01 04:26:18 UTC parent: 2a1ded8b0beac4b1d8d64b00cee7c7e5870dbe50 2012-05-01 03:28:14 UTC tags: trunk comment: Manually merged in the fork detection code. Also make most options work with partial match (user: matt) (P.S. thanks go to Jeffery Gong for figuring out the necessary SQL snippet) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] recent change: alt-root and its purpose?
On Sat, Apr 28, 2012 at 6:34 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Apr 28, 2012 at 7:03 AM, Leo Razoumov slonik...@gmail.com wrote: Hi All, Fossil design clearly separates a project repository database from a checkout database. It is explicitly stated in the Fossil documentation: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki Notice that the checkout database contains a pointer to the repository database but that the repository database has no record of the checkout databases. That means that a working checkout directory tree can be freely renamed or copied or deleted without consequence. Unfortunately, this in not true anymore since trunk [e604d483ee55] (2012-04-27 15:43:51). Now every time you fossil open a repository, the checkout root gets recorded into config portion of the project repo. All the checkouts ever created are displayed as alt-root entries by fossil info. The alt-root list can get long if one has many checkouts. By the way, fossil close does *NOT* remove the entry from the alt-root list (a bug??). The list only grows and never shrinks. A convenient way of dispensing with checkouts by rm -rf path-to-checkout leaves behind dangling references to non-existing directories. To the best of my knowledge there has been no discussion of this feature on the fossil-users or fossil-dev mailing lists. Therefore, I would greatly appreciate if someone can explain to me (1) What is the purpose of the feature. (2) Its intended use. (3) Rational for violating long-standing Fossil design principle that project repo database does not know its checkouts. I added this to help me keep track of where my check-outs are located. I keep all of my repositories in a single directory so I know where they all are. But my check-outs are scattered about hither and yon, according to their use and function. Many times I'll be looking at my growing collection of repositories and wonder where did I check this one out most recently. Or I'll be be working in a check-out and want to do some unrelated change on another branch and then wonder if I have other checkouts of the same repo sitting around anywhere. Isn't this information also stored in ~/.fossil as ckout:/path/to/ckout|/path/to/repo.fossil entries? I think I'd prefer to see the data recorded just once and actually I think the ~/.fossil file is a better place. Those entries should meet all your requirements as it maps each repo db to a checkout. Even if the repo db was moved there is enough data available to find the mapping and update the pointers in the _FOSSIL_ files. Since I can't get fossil ssh to work we are using rsync to sync fossils cross-site and with this feature every time someone blows away a repo and re-gets it the rsync logs will show a transfer implying that a change was made. Not a big deal but confusing and an annoyance nonetheless. If the decision is to stick with the new method then please consider removing the code that adds the ckout: entries to ~/.fossil as people will write automation that relies on one or the other and that can get messy and chaotic when there is not one canonical source data location. If you are thinking of moving or renaming a Fossil repository file, a listing of check-outs would be very useful in helping to determine what will break and need fixing. On a server, I often have multiple CGI scripts all pointing to the same repository. A similar feature, added at the same time, keeps track of all of the possible URLs for accessing a repository. On the main Fossil webserver for example, I just now did fossil info fossil.fossil and I see this: access-url: http://fossil-scm.hwaci.com/fossil 2012-04-28 access-url: http://fossil-scm.hwaci.com/index.html 2012-04-28 access-url: http://fossil-scm.org/fossil 2012-04-28 access-url: http://fossil-scm.org/index.cgi 2012-04-28 access-url: http://fossil-scm.org/index.html 2012-04-28 access-url: http://fossil-scm.org/xfer 2012-04-28 access-url: http://sqlite.org/debug1 2012-04-28 access-url: http://www.fossil-scm.org//index.html 2012-04-28 access-url: http://www.fossil-scm.org/fossil 2012-04-28 access-url: http://www.fossil-scm.org/index.html 2012-04-28 access-url: http://www.fossil-scm.org/xfer 2012-04-28 access-url: http://www.sqlite.org/debug1 2012-04-28 access-url: https://fossil-scm.org/index.html 2012-04-28 access-url: https://www.fossil-scm.org/fossil 2012-04-28 access-url: https://www.fossil-scm.org/index.html 2012-04-28 Those are the various URLs by which the Fossil repository has been accessed recently. Some are just multiple domain names assigned to the same IP address (www.fossil-scm.org vs fossil-scm.org vs fossil-scm.hwaci.com) but other actually reflect separate CGI scripts (index.html, index.cgi, fossil, xfer, and debug1). There are 65 other Fossil repositories on the same machine. A cross-reference like this
Re: [fossil-users] How to list merged files after update
On Fri, Apr 6, 2012 at 8:16 PM, Kriangkrai Soatthiyanont
kks...@gmail.comwrote:
It seems that `fossil changes` will show MERGED_WITH when you used
`fossil merge`, not when `fossil update` (to fix would fork error).
Anyway, after you have manually resolve conflicts, MERGED_WITH is
still shown, so it seems there is no way to know which files have
conflicts resolved, which files not.
By the way, here is my workaround to mark unresolved merge files:
% function fossil-changes {
fossil changes $@ |
sed -r 's/EDITED(\s+)(.*)/grep -q BEGIN MERGE
CONFLICT: \2 \\ echo U\1\2 || echo \0/e'; }
% fossil-changes
Ufile1
% vi file1# manually resolve conflicts
% fossil-changes
EDITEDfile1
I have added this snippet of code to the fsl wrapper. I hope you don't mind
:)
BTW, this is a serious annoyance for folks who don't use a gui tool for the
merge as it can be tedious to find all the files with conflicts. Is there
any solution planned?
How about adding flags in the _FOSSIL_ db for files with conflicts and
clear the flags on commit?
FYI, the wrapper can be found at:
http://kia...@chiselapp.com/user/kiatoa/repository/fsl
Thanks.
___
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] Question about tags and autosync...
On Wed, Apr 25, 2012 at 6:49 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Apr 25, 2012 at 6:51 PM, Michael L. Barrow mlbar...@barrow.mewrote: Firstly, I'm running: This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC Perhaps I'm confused, but the documentation for autosync being enabled says: autosync If enabled, automatically pull prior to commit or update and automatically push after commit or tag or branch creation. If the value is pullonly then only pull operations occur automatically. But, when I create a tag, it doesn't get pushed to the remote repo until I push or sync. Am I confused? Does it matter that this is a branch? What command did you use to create the tag? I don't see any code associated with the tag command that will do an autosync. My suspicious is that the documentation you site above is incorrect and that tag creation should be removed from the list of things that will trigger an automatic push. I'd like it if a tag *did* an autosync. Have the pros 'n cons been discussed before? -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** fossil-usershttp://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] Status of GUI for Windows?
On Fri, Apr 20, 2012 at 6:51 AM, Kostas Karanikolas karaniko...@gmail.comwrote: Hi, I'm the developer of Fuel. A reason why files are not being displayed could be that a view filter for some kind of file is active (Unknown files for example). Check the View menu. I have a new version coming up soon, so this a good time for bug reports or even feature requests. If you are still having problems, feel free to contact me directly. I just tried Fuel and it looks like it could be very useful. The first problem I ran into is that I can't seem to open up an already opened repo via samba. Does Fuel recognize the _FOSSIL_ file? I don't think it is related to samba. I was able to open a repo where the .fossil file was in the top directory. I think two ways of opening are needed: 1. Open an already 'opened' area, Fuel should be able to find the .fossil file by inspecting the _FOSSIL_ file. The .fossil file may be outside the opened repo area. 2. Open a .fossil file and create an open area but give the user an opportunity to browse to and or create the area to be used. Also, you may be amused to know that I went to check my laptop power cable and spent a few seconds trying to figure out a) why I wasn't plugged in and b) what had changed on my system to give me the new battery icon until I moused over the icon and realized it was Fuel. I guess I'd prefer something other than a battery as the default icon. How about a fuel canister with a fossil, you know fossil fuel, was that your original intent with the name? On 19 April 2012 19:12, Gilles gilles.gana...@free.fr wrote: Hello I find typing commands in a DOS box not as convenient as right-clicking on a file/folder in Windows Explorer, to the point where I don't use Fossil as often as I'd like when working on scripts/programs and would like to keep tracks of things. So I wanted to check what the status is on the existing GUI projects. Googling for fossil gui returns the following projects: - (Java) http://code.google.com/p/jurassic-fossil/ - (.Net) http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil/ - (Qt) http://code.google.com/p/fuel-scm/ Apparently, 1. SharpFossil is just a library, the application is WinFossil, but it doesn't seem to be under actual development 2. Fuel-SCM seems like the most advanced and (I don't like Java, and find .Net apps too slow to load; I'd rather use a native Win32 application, but Qt will have to do), but I can't figure out what to do once I hit File Open my.repo (right side is blank) Is this correct? Are there other tools I should know about? Thank you. ___ 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.exe: lack both primary and secondary files
On Sat, Apr 14, 2012 at 11:35 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Apr 14, 2012 at 3:27 AM, Petr Ferdus petr...@centrum.cz wrote: Hello, I am trying to merge my local fossil repo with trunk and all I receive is message fossil.exe: lack both primary and secondary files. I thought it might be related to use of my patched version of fossil.exe but the same message appears with latest windows binary from fossil site. Previously, I have merged my local fossil repo literally hundred’s times so I am quite confused what might went wrong. I don't understand this either. The error is more of an assertion than something that a user ought to see - it is not suppose to ever occur and it indicates that something is wrong with the merge logic. As far as I know, it has never come up before. If you can figure out how to reproduce the problem, that would be a big help. I've seen this when merging from a more recent check in to an older check in. Checking out the newer version and merging the old version into it seemed to fix it. Rebuilding repo does not help. I know the message comes from pivot.c [ http://www.fossil-scm.org/fossil/artifact/01042d5f6?ln=87] as used in merge.c [ http://www.fossil-scm.org/fossil/artifact/0735646a51a?ln=167] Last time I pulled artifact from fossil canonical server I received a message *** time skew *** server is slow by 32.3 seconds. Could this lead to perceived problem? What else should I try to solve problem with merge? Thanks. Peter c:\soft\msys\home\user\fossilfossil ver This is fossil version 1.22 [5dd5d39e7c] 2012-03-19 12:45:47 UTC c:\soft\msys\home\user\fossilfossil rebu c:\soft\bin\myfossilclone.fossil 100.0% complete... c:\soft\msys\home\user\fossilfossil merge trunk c:\soft\msys\home\user\fossil\fossil.exe: lack both primary and secondary files c:\soft\msys\home\user\fossilfossil merge --debug trunk c:\soft\msys\home\user\fossil\fossil.exe: lack both primary and secondary 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] Request feature : choose directory for the addremove command
On Fri, Apr 13, 2012 at 5:59 AM, vince vinc...@neuf.fr wrote: Hello, the command addremove synchronize the repository with the working directory. So that fossil adds files that have nothing to do with my projects, such as the file fossil.exeitself! We should be able to choose from which directory we want to do the addremove. Or we can change the working directory. thanks. If fossil is trying to add files such as fossil.exe then you may have opened your fossil repo at the root of your drive. Search for a file _FOSSIL_ Every file and directory under the level where you find the _FOSSIL_ is inside your repo. Note that you can use the ignore-glob mechanism to tell fossil to ignore files that should not be tracked or managed by fossil. Either add a file .fossil-settings/ignore-glob with one pattern on each line for the files or browse to settings in the ui and add your remove patterns in the ignore-glob field there. ___**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil: unable to create directory /var/tmp
We are seeing the following error in some users environments and I have not been able to root cause it yet. Does anyone have suggestions on how to debug this? fossil gdiff --from abce3460ac --to c628b11818 ./abcdef.rb fossil: unable to create directory /var/tmp ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl wrapper updated
On Wed, Mar 28, 2012 at 10:32 PM, Matt Welland estifo...@gmail.com wrote: Hmmm... I haven't tested from a fresh install in a while now that I think of it.There is likely something in my environment that masks the problem you are seeing. I'm having trouble with the fossil binary 1.22 downloaded from the official site. I think I need to build from scratch and don't have time right this sec, can you test the following commands and let me know if they work for you? fsl repo fsl repo ls Thanks, Matt -=- On Wed, Mar 28, 2012 at 10:00 PM, Michael Richter ttmrich...@gmail.comwrote: Um... This is just utterly failing for me. When I type fsl I get bizarre messages. I didn't see any issues when I ran in a fresh install. I did have to compile fossil to get ssl working but that is unrelated. One thing I do see is that fossil commands is mentioned in the default help but there doesn't appear to actually be a fossil commands help command. Here's the repo information I've got: $ fossil timeline === 2012-03-28 === 20:23:06 [f005e8a101] *CURRENT* Removed mention of dbinit from help as it isn't needed any more (user: mrwellan tags: trunk) 20:22:08 [75f4d3f79c] Added mention of pass-thru of fossil commands in the help (user: mrwellan tags: trunk) 19:44:16 [048bd4bc30] Added FOSSILEXE variable to allow overriding of where fossil comes from, set sqlite3 to default to version found on path, added alias for ls to list (user: mrwellan tags: trunk) === 2012-03-27 === 16:56:59 [8eb9dd6b23] Fixed broken initialization (user: mrwellan tags: trunk) === 2012-03-23 === 18:23:06 [111abefc7c] Added primitive pre and post hooks to repo create and get. Added support for .fslcustom in the same dir as fsl (user: mrwellan tags: trunk) 17:18:27 [5aa3c15c17] Added some hard coding to force find sqlite3 in /usr/bin if it exists (user: mrwellan tags: trunk) === 2012-02-23 === 18:58:13 [fe9b4b1aa4] Changes to wiki page [fsl wrapper] (user: mrwellan) 18:50:27 [a9bee7027c] Changes to wiki page [Implemented work-arounds and fixes] (user: mrwellan) 18:49:14 [b1f768ed47] Changes to wiki page [Implemented work-arounds and fixes] (user: mrwellan) Here's what happens when I try to use it: $ fsl Usage: /usr/local/bin/fossil COMMAND ... or: /usr/local/bin/fossil help -- for a list of common commands or: /usr/local/bin/fossil help COMMMAND -- for help with the named command or: /usr/local/bin/fossil commands -- for a list of all commands $ fsl commands /usr/local/bin/fossil: /usr/local/bin/fossil: unknown command: commands /usr/local/bin/fossil: use help for more information So what you're reporting for the UI is ... not what I'm seeing. On 29 March 2012 04:26, Matt Welland estifo...@gmail.com wrote: The fsl convienence wrapper has had a few updates and seems to be working pretty well for us. I'm announcing it (again) to the fossil list perchance it is of use to anyone else. Features: 1. areas. Store your fossils in different directories, e.g. public, private, customera, etc. List the areas or fossils in each area. Our team is working with nearly 100 different fossils (and growing every day) over four or five areas so for us this is really helpful. 2. Eased creation and getting of repos, e.g.: fsl repo get public scripts, this hides the clone/open cycle from users which makes ramping up on fossil much easier. 3. Simple, override-able set up actions, we use this to set the default areas for users and to set allow-symlinks in the global settings. Symlinks are a particularly troublesome issue for us and we need repos and users to always default to allow-symlinks. 4. Simple but very limited hooks 5. Misc tweaks; tweak timeline output to be Unix scriptaholic friendly, -f (force) for mv, hierarchical move that works like Unix fsl is just a simple bash script which should work on most Unixes with little to no install effort. It might work on Cygwin but I've not tested it. You can get it at: http://chiselapp.com/user/kiatoa/repository/fsl fsl repo help The fsl convienence wrapper. Copyright (C) 2012 Matthew Welland, License GPL 2.0 Usage: fsl repo cmd args Or:fsl fossil commands where repo cmd is one of ls ls area get area reponame addarea areaname path droparea areaname create areaname reponame [-template templatename] import areaname reponame fossilfile Also available, move with Unix semantics: fsl mv src1 [src2 ...] targ Move with -f also does corresponding Unix mv fsl mv -f src1 [src2 ...] targ Note: timeline and leaves output is de-wrapped More at: http://chiselapp.com/user/kiatoa/repository/fsl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Perhaps people
[fossil-users] fsl wrapper updated
The fsl convienence wrapper has had a few updates and seems to be working pretty well for us. I'm announcing it (again) to the fossil list perchance it is of use to anyone else. Features: 1. areas. Store your fossils in different directories, e.g. public, private, customera, etc. List the areas or fossils in each area. Our team is working with nearly 100 different fossils (and growing every day) over four or five areas so for us this is really helpful. 2. Eased creation and getting of repos, e.g.: fsl repo get public scripts, this hides the clone/open cycle from users which makes ramping up on fossil much easier. 3. Simple, override-able set up actions, we use this to set the default areas for users and to set allow-symlinks in the global settings. Symlinks are a particularly troublesome issue for us and we need repos and users to always default to allow-symlinks. 4. Simple but very limited hooks 5. Misc tweaks; tweak timeline output to be Unix scriptaholic friendly, -f (force) for mv, hierarchical move that works like Unix fsl is just a simple bash script which should work on most Unixes with little to no install effort. It might work on Cygwin but I've not tested it. You can get it at: http://chiselapp.com/user/kiatoa/repository/fsl fsl repo help The fsl convienence wrapper. Copyright (C) 2012 Matthew Welland, License GPL 2.0 Usage: fsl repo cmd args Or:fsl fossil commands where repo cmd is one of ls ls area get area reponame addarea areaname path droparea areaname create areaname reponame [-template templatename] import areaname reponame fossilfile Also available, move with Unix semantics: fsl mv src1 [src2 ...] targ Move with -f also does corresponding Unix mv fsl mv -f src1 [src2 ...] targ Note: timeline and leaves output is de-wrapped More at: http://chiselapp.com/user/kiatoa/repository/fsl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl wrapper updated
Hmmm... I haven't tested from a fresh install in a while now that I think of it.There is likely something in my environment that masks the problem you are seeing. I'm having trouble with the fossil binary 1.22 downloaded from the official site. I think I need to build from scratch and don't have time right this sec, can you test the following commands and let me know if they work for you? fsl repo fsl repo ls Thanks, Matt -=- On Wed, Mar 28, 2012 at 10:00 PM, Michael Richter ttmrich...@gmail.comwrote: Um... This is just utterly failing for me. When I type fsl I get bizarre messages. Here's the repo information I've got: $ fossil timeline === 2012-03-28 === 20:23:06 [f005e8a101] *CURRENT* Removed mention of dbinit from help as it isn't needed any more (user: mrwellan tags: trunk) 20:22:08 [75f4d3f79c] Added mention of pass-thru of fossil commands in the help (user: mrwellan tags: trunk) 19:44:16 [048bd4bc30] Added FOSSILEXE variable to allow overriding of where fossil comes from, set sqlite3 to default to version found on path, added alias for ls to list (user: mrwellan tags: trunk) === 2012-03-27 === 16:56:59 [8eb9dd6b23] Fixed broken initialization (user: mrwellan tags: trunk) === 2012-03-23 === 18:23:06 [111abefc7c] Added primitive pre and post hooks to repo create and get. Added support for .fslcustom in the same dir as fsl (user: mrwellan tags: trunk) 17:18:27 [5aa3c15c17] Added some hard coding to force find sqlite3 in /usr/bin if it exists (user: mrwellan tags: trunk) === 2012-02-23 === 18:58:13 [fe9b4b1aa4] Changes to wiki page [fsl wrapper] (user: mrwellan) 18:50:27 [a9bee7027c] Changes to wiki page [Implemented work-arounds and fixes] (user: mrwellan) 18:49:14 [b1f768ed47] Changes to wiki page [Implemented work-arounds and fixes] (user: mrwellan) Here's what happens when I try to use it: $ fsl Usage: /usr/local/bin/fossil COMMAND ... or: /usr/local/bin/fossil help -- for a list of common commands or: /usr/local/bin/fossil help COMMMAND -- for help with the named command or: /usr/local/bin/fossil commands -- for a list of all commands $ fsl commands /usr/local/bin/fossil: /usr/local/bin/fossil: unknown command: commands /usr/local/bin/fossil: use help for more information So what you're reporting for the UI is ... not what I'm seeing. On 29 March 2012 04:26, Matt Welland estifo...@gmail.com wrote: The fsl convienence wrapper has had a few updates and seems to be working pretty well for us. I'm announcing it (again) to the fossil list perchance it is of use to anyone else. Features: 1. areas. Store your fossils in different directories, e.g. public, private, customera, etc. List the areas or fossils in each area. Our team is working with nearly 100 different fossils (and growing every day) over four or five areas so for us this is really helpful. 2. Eased creation and getting of repos, e.g.: fsl repo get public scripts, this hides the clone/open cycle from users which makes ramping up on fossil much easier. 3. Simple, override-able set up actions, we use this to set the default areas for users and to set allow-symlinks in the global settings. Symlinks are a particularly troublesome issue for us and we need repos and users to always default to allow-symlinks. 4. Simple but very limited hooks 5. Misc tweaks; tweak timeline output to be Unix scriptaholic friendly, -f (force) for mv, hierarchical move that works like Unix fsl is just a simple bash script which should work on most Unixes with little to no install effort. It might work on Cygwin but I've not tested it. You can get it at: http://chiselapp.com/user/kiatoa/repository/fsl fsl repo help The fsl convienence wrapper. Copyright (C) 2012 Matthew Welland, License GPL 2.0 Usage: fsl repo cmd args Or:fsl fossil commands where repo cmd is one of ls ls area get area reponame addarea areaname path droparea areaname create areaname reponame [-template templatename] import areaname reponame fossilfile Also available, move with Unix semantics: fsl mv src1 [src2 ...] targ Move with -f also does corresponding Unix mv fsl mv -f src1 [src2 ...] targ Note: timeline and leaves output is de-wrapped More at: http://chiselapp.com/user/kiatoa/repository/fsl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ fossil-users mailing list fossil-users@lists.fossil
Re: [fossil-users] Thanks and some questions
On Mon, Mar 19, 2012 at 4:12 AM, mail...@nym.mixmin.net wrote: [snip] I often add programs to the project and I don't always remember to tell fossil about them. What is the correct way to use fossil so when you work on new projects where you don't have everything that will ultimately be part of the project in your directory from the beginning? What should I be doing to make sure fossil knows about all the new code? add doesn't seem to work, and stat or chan doesn't flag newly created files that I haven't already added. This is a bit disturbing and I'm afraid new modules will go untracked. I find myself using add * or addr. addr should usually be ok but I don't like taking the chance to delete something. I realize unless you shun nothing is actually lost but I don't know how it works and what problems I could cause by addr. My question is really how should I be doing this workflow. I think you want the fossil extra command to tell you what files are in your working folder that are not under management. And the fossil addremove command which will recursively descend through your working folder adding and removing files as necessary so that everything is under management again. Thanks, I missed the extra command, that sounds helpful but I guess what I would have preferred, since it doesn't take any extra action on the users's part, might be to see all the files that exist that aren't managed, when I do fossil stat or fossil change. In other words I'm looking for something that goes out of its way to tell me hey, do you realize you have new files here that fossil isn't managing? Specifically this happens to me a lot because I'm doing some work right now on text processing and I have a lot of junk files in my working directories I use as input for my tests. I don't tend to want to manage this stuff because I can grab more text and create new test cases easily. If I do fossil addr all the time I find tons of crap gets added and deleted from the repo and that bothers me since it shouldn't have been there at all and it just gets dragged along because I don't have a way to be notified when I add source code that I *do* want managed. Either I keep doing addr (or now extra and figure it out manually) and get my source and junk files added, or I lose the junk and the new source code because I don't always remember what's been added and what hasn't. I guess I need to get used to managing the tools more than I have been. In the past I worked on established products and we almost never added new source files. Now I am writing a lot more code and need to rethink how I am managing that process. Depending on if your files fit a nice set of patterns you may want to consider using ignore-glob to keep from seeing your irrelevant files. The methodology I encourage on our team is that a fossil extras should always be clean, i.e. there should be no extras. Any extras should be either added to fossil with fossil add or added to the glob list. To make that a bit easier we use the .fossil-settings/ignore-glob file instead of the setting via the ui. Don't forget to fossil add the .fossil-settings/ignore-glob file. We commonly have one or more build directories where various processes are run and ignore them all with a */build/* pattern or similar. However do be careful with blanket ignores. If I recall correctly fossil behavior is a little odd when it comes to controlled files that match an ignore pattern. I seem to remember that a modified controlled file masked by a ignore does not show up in fossil status I am not criticizing fossil (it's great!), I am just trying to understand how to use it efficiently for the way I work, rather than trying to adjust the way I work for the benefit of the scm I'm using. In the end I will probably have to do a little of both. For me this is the flip side of fossil telling you if you had a file under management and you deleted it, when you do a stat, changes, or commit. That works great and gives a red flad- hey, I can't find file a and file b. Then again, I admit what I was thinking of may bring problems with it because if you have ignored dozens or hundreds of files when you do a stat or changes or commit you don't want to see those. Maybe that logic already exists. After I hear your comments I'll try to work with this more and get a better understanding. But I am also interested in hearing how people who are writing a lot of new code and also keep test and other junk in the project directory tree are using fossil. [snip] ___ 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] problem with illegal characters
I'm in the mood for some long winded editorializing Bob Coder is moving his development team off of AntiquatedSCM and on to one of the fancy new distributed SCMs that are all the rage. They look at git but it seems kinda complicated and one of the devs suggests Fossil. Wow, nice, simple, elegant, reliable, data storage design that looks trustworthy, solves multiple problems with one executable. Cool. But in the evaluation it comes to light that some legacy files with funky characters can't be checked in and the only two solutions are to throw away or rewrite multiple megs of test cases or to maintain a private branch of the Fossil source. Neither option is tenable and Fossil is eliminated. So Fossil loses another potential advocate due to being devoted to a philosophy of enforcing adherence to the lowest common denominator and the ever pragmatic (albeit, bloody complicated) git gains another user. Sure, it is a silly story and who cares, fossil was not written to be everything to everyone. But still, we've seen at least one real world variant of this story reported to the list A strongly worded warning makes sense but I personally think a no-alternative enforcement does not. IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. On Wed, Mar 7, 2012 at 3:16 PM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 14:30, sky5w...@gmail.com wrote: because of the hassle of re-working their multitudes of files or create/maintain Fossil branches using Richard's suggestion. If square bracket limitation is the only thing that make fossil unacceptable to you then, please, consider making your own fossil branch as Richard suggested. Actually, I found maintaining my own fossil branch quite easy. And my changes are larger and more intrusive that commenting out couple of lines of code. --Leo-- ___ 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] Overwriting binary files on 'update'
On Thu, Mar 1, 2012 at 8:03 AM, Leo Razoumov slonik...@gmail.com wrote: 2012/3/1 Lluís Batlle i Rossell vi...@viric.name: Hello, in fossil 1.21, I've a modified openoffice file. Then I run fossil update, and it tells me there is a merge conflict with a binary file, that it cannot merge. What I'm surprised about is that fossil overwrites my local changes with the incoming ones. And the file with local changes disappears, only available again on 'fossil undo'. Should't fossil better leave additional files in the directory, as with the -baseline, -original, and -merge? Please, correct me if I am wrong, but I noticed that fossil update also overrides unmanaged files (both binary and text). I am not sure that their contents are backed up. fossil update will also bring back files that have been fossil rm'd and physically removed. It'd be nice to be given the opportunity to abort as this can be a real pain. --Leo-- ___ 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] fsl wrapper script, might be of use to others ...
I have written a wrapper script for fossil that makes some minor adaptions to accommodate a somewhat more Unix centric use model and where a large number of repos must be dealt with. In the off chance that others may find it useful I'm making it available at: http://chiselapp.com/user/kiatoa/repository/fsl This is an initial release with almost no documentation and it probably has bugs so if you try it keep backups! I am interested in feedback or ideas related to the script. Matt -=- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] With jimtcl available can we have hooks that trigger tcl scripts stored in the db?
On Mon, Feb 13, 2012 at 1:43 PM, Steve Bennett ste...@workware.net.auwrote: On 14/02/2012, at 4:22 AM, Matt Welland wrote: I think it may be very useful if it was possible to call tcl scripts stored in the repo db (revision controlled files or wiki pages?) at pre/post commit and other interesting times. I know hooks were previously not accepted since making things consistent between Windows and Linux was difficult. But that concern should be addressed if the hooks call tcl or th1 scripts instead of directly sending commands to the OS. It looks like jimtcl supplies os.fork, os.wait etc. but I didn't see a posix system, can jimtcl run commands on Unix? Yes, indeed! You want the 'exec' command - http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html#_exec You can try this out with the 'jimtcl' branch of fossil. Hi Steve, This sounds cool, so is the mechanism to call a jimtcl routine implemented on various actions and if so then how do I, for example, call a tcl script when sync is completed? Thanks, Matt -=- Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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] zip/tar patch
On Sat, Feb 11, 2012 at 7:55 AM, frantisek holop min...@obiit.org wrote:
any interest in this simple patch?
I think the proposed behavior is a good way to go.
hmm, on Tue, Feb 07, 2012 at 07:48:30PM +0100, frantisek holop said that
hi there,
the motivation for this patch was that the zip and tarball links
from the web ui get a filename and checkout for free, while they
are a mandatory parameters for the command line.
so i tried to unify it a bit: the default archive name is now both
from web and cli the same, a lowercased project name followed by the
artifact ID. spaces are substituted with '-'.
$ fossil zip
fossil-030035345c.zip: 2944427 bytes
$ fossil zip tip
fossil-030035345c.zip: 2944427 bytes
$ fossil zip -o f.zip
f.zip: 2944427 bytes
$ fossil zip -o f.zip tip
f.zip: 2944427 bytes
$ fossil tar
fossil-030035345c.tgz: 2944427 bytes
$ fossil tar tip
fossil-030035345c.tgz: 2944427 bytes
$ fossil tar -o f.tgz
f.zip: 2944427 bytes
$ fossil tar -o f.tgz tip
f.zip: 2944427 bytes
$ fossil help zip
Usage: fossil zip [--name DIRECTORY] [-o OUTPUTFILE]
[-R REPOSITORY] [VERSION]
Generate a ZIP archive containing VERSION of the checkout.
If VERSION is omitted, the current checkout is used.
The name of the resulting archive can be set using the -o option,
otherwise it will be derived from the project name followed by the
check-in's artifact ID. Unless the --name option is specified, the
the top-level directory inside the archive will have the same name.
Options:
--name DIRECTORY Name of the top-level directory inside
the archive.
-o OUTPUTFILE Name of the archive.
-R|--repository FILE Use the repository in FILE.
See also: tarball
--- src/info.c
+++ src/info.c
@@ -500,11 +500,18 @@
@ td%h(zUser) @ %h(zIpAddr) on %s(zDate)/td/tr
}
db_finalize(q);
}
if( g.perm.History ){
- const char *zProjName = db_get(project-name, unnamed);
+ char *zProjName = db_get(project-name, unnamed);
+ int i;
+ for(i=0; istrlen(zProjName); i++){
+zProjName[i] = fossil_tolower(zProjName[i]);
+if( zProjName[i]==' ' ){
+ zProjName[i] = '-';
+ }
+ }
@ trthTimelines:/thtd
@ a href=%s(g.zTop)/timeline?f=%S(zUuid)family/a
if( zParent ){
@ | a href=%s(g.zTop)/timeline?p=%S(zUuid)ancestors/a
}
@@ -526,16 +533,14 @@
@ /td/tr
@ trthOthernbsp;Links:/th
@ td
@ a href=%s(g.zTop)/dir?ci=%S(zUuid)files/a
if( g.perm.Zip ){
-char *zUrl = mprintf(%s/tarball/%s-%S.tar.gz?uuid=%s,
- g.zTop, zProjName, zUuid, zUuid);
-@ | a href=%s(zUrl)Tarball/a
+@ | a
href=%s(g.zTop)/tarball/%s(zProjName)-%S(zUuid).tgz=%s(zUuid)
+@ Tarball/a
@ | a
href=%s(g.zTop)/zip/%s(zProjName)-%S(zUuid).zip?uuid=%s(zUuid)
@ ZIP archive/a
-fossil_free(zUrl);
}
@ | a href=%s(g.zTop)/artifact/%S(zUuid)manifest/a
if( g.perm.Write ){
@ | a href=%s(g.zTop)/ci_edit?r=%S(zUuid)edit/a
}
--- src/tar.c
+++ src/tar.c
@@ -525,42 +525,63 @@
}
/*
** COMMAND: tarball*
**
-** Usage: %fossil tarball VERSION OUTPUTFILE [--name DIRECTORYNAME]
[-R|--repository REPO]
+** Usage: %fossil tarball [--name DIRECTORY] [-o OUTPUTFILE]
+** [-R REPOSITORY] VERSION
+**
+** Generate a compressed tarball archive containing VERSION of the
+** project. If VERSION is omitted, the current checkout is used.
+**
+** The name of the resulting archive can be set using the -o option,
+** otherwise it will be derived from the project name followed by the
+** check-in's artifact ID. Unless the --name option is specified, the
+** the top-level directory inside the archive will have the same name.
+**
+** Options:
+** --name DIRECTORY Name of the top-level directory inside
+** the archive.
+** -o OUTPUTFILE Name of the archive.
+** -R|--repository FILE Use the repository in FILE.
**
-** Generate a compressed tarball for a specified version. If the --name
-** option is used, its argument becomes the name of the top-level
directory
-** in the resulting tarball. If --name is omitted, the top-level
directory
-** named is derived from the project name, the check-in date and time,
and
-** the artifact ID of the check-in.
+** See also: zip
*/
void tarball_cmd(void){
int rid;
Blob tarball;
const char *zName;
+ const char *fName;
+ int wrote;
zName = find_option(name, 0, 1);
+ fName = find_option(o, o, 1);
db_find_and_open_repository(0, 0);
- if( g.argc!=4 ){
-usage(VERSION OUTPUTFILE);
Re: [fossil-users] Retro side-by-side diffs
Seconded. The hidden lines receive more emphasis than the change. Do a tkdiff on the same change and it is immediately obvious what the change is. I checked meld, tkdiff and xxdiff and in all of them the actual character that was removed is also highlighted making it immediately obvious what changed. It was not immediately obvious to me what changed in either the colored or retro examples. If fossil can't easily match the capability of an external tool then my vote would be to go with the retro. On Sat, Feb 4, 2012 at 6:36 AM, Ramon Ribó ram...@compassis.com wrote: For me, much better with the colors. Maybe taking out the violet of the hidden lines. It helps a lot to focus the attention to the correct place. RR El 04/02/2012 13:24, Richard Hipp d...@sqlite.org escribió: On Sat, Feb 4, 2012 at 5:08 AM, altufa...@mail.com wrote: Same here. I like the colorful diff. But I would like to know (sorry if I missed) what's the problem with color sbs and what are we getting with retro sbs? Here is an example, two different websites showing the same Fossil project (TCL), one with the traditional colorful diff and the other with the new retro diff: (1) http://core.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1 (2) http://mirror1.tcl.tk/tcl/ci/4ebc3a8e1e?sbs=1dw=67 The change of this check-in is a single line of code - indeed a single character on that one line. With (1), my eyes are distracted by a bunch of needless coloration, and I have to stare at the screen for a second or two before I can discern what has actually changed. I tried using colored diffs for a while, but I eventually gave up in frustration. They are simply not useful to me. I can read the old-style unified diffs faster. In (2), on the other hand, I can clearly and immediately see that one line has changed. The change pops out at me. I don't have to think about it - it is just there. - Altu - Original Message - From: Weber, Martin S Sent: 02/03/12 11:03 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Retro side-by-side diffs On 2012-02-03 12:31 , Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I'm for color-coded. All of the reasons have already been listed in the thread. Same here. -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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Retro side-by-side diffs
On Fri, Feb 3, 2012 at 8:25 AM, Richard Hipp d...@sqlite.org wrote: For some time now, the SQLite and Fossil websites have been running on the retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a vastly simplified format for the side-by-side diffs that omits all of the colors and decoration and provides plain-text output - essentially the same output as you would get on the command-line using the -y flag. Example: http://www.sqlite.org/src/info/21695c3476 I find the retro side-by-side diff to be much more readable, which is why I am using it on the SQLite and Fossil websites, as well as on my desktop. And I've heard no complaints from users about the retro sbsdiffs on the website. But before I merge the retro-sbsdiff branch into trunk (and hence purge the existing colorful sbs diff from the trunk) I thought I would as for community feedback. Are there strong preferences one way or another? I will miss the colors as I tend to rely on color in tools like tkdiff, meld and xxdiff to give me a big picture view and to draw my eye to the changes. The compressed summary (in the center scroll bar in tkdiff and on the rhs in meld is extremely useful but I doubt that can be easily replicated in fossil so maybe keeping it simple in the browser and leaving the more powerful interface to external tools makes sense. Just my $0.02 -- 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] fossil rm followed by unix rm followed by update and files come back, is this desirable?
If I do: fossil rm some/file.txt rm some/file.txt ...do stuff... fossil update then some/file.txt is resurrected which is really really annoying when you just got your build to work and then because files that shouldn't be there suddenly reappear and things break. I can see where might be some controversy in the behavior of fossil update in this situation. Is there a good practice that avoids the hassle from the files coming back? I've been telling folks to update often to stay in sync and in this case that can cause annoyance and time wasting. The one possible methodology I can see is to use stash but it seems both overly complicated and actually this behavior seems to violate this phrase in the fossil update help Any uncommitted changes are retained and applied to the new checkout. : fossil rm some/file.txt rm some/file.txt ...do stuff... fossil stash fossil update fossil stash pop ___ fossil-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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.comwrote: On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. -- Dmitry Chestnykh http://www.codingrobots.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] How to limit fossil diff output to just names of the changed files?
On Tue, Jan 31, 2012 at 11:41 AM, Leo Razoumov slonik...@gmail.com wrote: Hi All, I am a new Fossil SCM user and it is my first posting to this mailing list. Please, forgive me if what I am asking has been discussed and answered here before. When I do sh$ fossil diff --from ver1 --to ver2 I get the entire contextual diff of the changes between the said commits. How could I get only the _names_ of the changed files _without_ contextual differences? Something like git diff --name-status or git diff --name-only. I know I can see the list of the names of changed files via fossil ui but I prefer to list the files using fossil command line interface, for I can grep the output further. fossil could do with a little more power on the command line. Passing remaining parameters to diff would be useful. Here is a crude work around for you: $ fossil set diff-command 'diff $DIFFPARAMS' $ DIFFPARAMS='-q' fossil diff -r 7ad3e --Leo-- ___ 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] PDF as embedded documentation
On Fri, Jan 20, 2012 at 5:40 PM, Tomek Kott tkott.s...@gmail.com wrote: Hi Matt, Would you mind sharing that make file? I'm starting a project with Lyx myself, and that solution seems pretty great! Well there isn't much to it, it may well not work for more complex documents: all : html/megatest.html megatest.lyx html/megatest.html : megatest.lyx rm -rf megatest.html.LyXconv lyx -e html megatest.lyx cp megatest.html.LyXconv/* html/ fossil add html/* megatest.pdf : megatest.lyx lyx -e pdf megatest.lyx I thought the embedded docs do preserve the fossil header (such as the landing page of fossil-scm.org, which is an 'embedded' doc, at least how I understood the term.) Are we thinking of different headers / embedded docs? Well in my case when you click on the link to the embedded documentation (the output from lyx in this case) the fossil heading, menu etc. goes away. I may not have it set up optimally however. Thanks, Tomek On Fri, Jan 20, 2012 at 7:28 PM, Matt Welland estifo...@gmail.com wrote: I have been doing exactly the same thing. A LaTeX (lyx) document plus a make file that writes out html and a pdf and it seems to work great. I suppose it may depend on just how much in the way of hard to compress pictures comprise your document. I do wish there was a way with the embedded documentation to preserve the fossil header and display the html but that is a very minor thing. On Fri, Jan 20, 2012 at 5:22 PM, Guilherme P. de Freitas guilhe...@gpfreitas.com wrote: ___ 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] Work from Windows and Linux simultaneously.
Essentially the request here is to support a relative path to the .fossil file in the _FOSSIL_ file. This would be very useful for me and as far as I can tell there is no good technical reason why it would not work just fine. John's desired work strategy can easily be supported with the relative path suggestion. For me has has been *really* annoying to have mounted a disk with a fossil dir such that the relative location to the .fossil is unchanged but the absolute location is different and not be able to run fossil status to check that everything was committed. Another example were this was really annoying is where I mounted a directory in a virtualbox instance and again, no fossil operations are possible. A third example ; to keep things simple for new users I wrote a wrapper script that makes getting a repo a single command. The wrapper puts the .fossil file inside a directory .fossil in the repo. Now if the user decides to move the fossil area then fossil commands will no longer work. All of these can be worked around but it sure seems lame. I see two possible strategies on how to implement this: i. Use the path to the .fossil as given on clone command line as-is. ii. If the path to the .fossil lies inside the clone area then use a relative path. Either approach would work for me. The second seems more conservative but may be more work to implement. Just my $0.02 On Sat, Jan 28, 2012 at 1:26 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Jan 28, 2012 at 9:23 PM, John Found johnfo...@evrocom.net wrote: Unfortunately the suggested workaround is not very useful, because I need only one check out, because the changes I make in Linux, later must be tested in Windows and vice versa. At the end, when everything works I can make commit with all changes. How does having two checkouts prohibit you testing from both platforms? You develop on windows, check in the changes, switch to linux, update that checkout and test the changes there. _FOSSIL_ _has_ to record where the original .fossil file is (because in 99% of cases it is NOT the current directory, and even if it was always in the current dir, it wouldn't know the file's name). The approach of trying to recycle a single checkout for two platforms is the source of your grief, and the workaround is to stop doing it. -- - 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
Re: [fossil-users] Work from Windows and Linux simultaneously.
In John's case the relative path lies on the same disk and inside the working area and it would work fine on both Windows and Linux. This is also true in every one of the examples I gave. I think the simplest solution is that on fossil open the path used is stored in the _FOSSIL file. Document in the help that unless you know what you are doing always use the full path and voilà, done. I suppose as an extra layer of keep the newbie questions to a minimum you could require a -f (i.e. force) to use relative paths. I know that developer time is a premium and this could well end up on the wish list as a low priority but I don't see any compelling technical reasons why relative paths wouldn't work fine. On Sat, Jan 28, 2012 at 2:00 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Jan 28, 2012 at 9:58 PM, Matt Welland estifo...@gmail.com wrote: John's desired work strategy can easily be supported with the relative path suggestion. Relative paths don't work cross-drive on Windows. They can only work on the same drive. -- - 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
Re: [fossil-users] Work from Windows and Linux simultaneously.
On Sat, Jan 28, 2012 at 2:54 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Jan 28, 2012 at 3:58 PM, Matt Welland estifo...@gmail.com wrote: Essentially the request here is to support a relative path to the .fossil file in the _FOSSIL_ file. i. Use the path to the .fossil as given on clone command line as-is. ii. If the path to the .fossil lies inside the clone area then use a relative path. http://www.fossil-scm.org/fossil/ci/a7248d8fb9?sbs=1 The pathname of the *.fossil file is now stored in the _FOSSIL_ file exactly as it is given on the open command (not the clone command) which is what I think you meant to say. Yep, I did mean open. Downloaded, compiled and tested and it works perfect! Thanks! -- 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] PDF as embedded documentation
I have been doing exactly the same thing. A LaTeX (lyx) document plus a make file that writes out html and a pdf and it seems to work great. I suppose it may depend on just how much in the way of hard to compress pictures comprise your document. I do wish there was a way with the embedded documentation to preserve the fossil header and display the html but that is a very minor thing. On Fri, Jan 20, 2012 at 5:22 PM, Guilherme P. de Freitas guilhe...@gpfreitas.com wrote: ___ fossil-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 not tracking directories / dir artifacts after switching branches
I think a good algorithm would be quite simple: If a file being removed as part of a checkout to a different branch is the last file in a directory and the directory is not listed in the empty-dirs entry then remove the directory. This should have zero negative impact on anyone and during the early phases of a project where things are moving around a lot it would be really really appreciated to not see the droppings from a different branch which can be very confusing. Especially to learners and refugees from other SCM tools. Some of the things that have been mentioned on the list would be better handled as tickets. What is the current process for submitting a ticket? A quick perusal of the fossil-scm.org site didn't yield any hints for me. Thanks! Matt -=- On Thu, Dec 22, 2011 at 5:00 PM, Martin Gagnon eme...@gmail.com wrote: On 2011-12-22, at 15:43, Justin Gedge justin.ge...@gmail.com wrote: In one of my projects I've been working on a development branch. In the new branch- I've moved several directories around. All the files are tracked perfectly- but when switching between branches, my work space, or checkout area has these artifacts, or empty directories from the previous checked out branch. All the files are being moved and handled properly, which is good, but it's annoying after cleaning up and re-architecting a development branch- only to have these directory artifacts lying all over the place when I switch between branches. I can write a script to clean out and remove empty directories but it would be nice if this was handled by the scm. If it remove directories, what fossil should do if there's some untracked files in those directories, delete the whole directory with all those files in it? Just wondering. May be another case for a so multipurpose -f switch ? ;) -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil not tracking directories / dir artifacts after switching branches
On Thu, Dec 22, 2011 at 6:15 PM, Richard Hipp d...@sqlite.org wrote: The rmdir(2) system call on Posix is a no-op if the directory is not empty. So I was thinking that we could just invoke rmdir() (or _rmdir() on windows) on the directory of a file every time a file is deleted, and let the OS worry about whether or not the directory is empty. But then I read this on the Linux rmdir(2) manpage: Infelicities in the protocol underlying NFS can cause the unexpected disappearance of directories which are still being used. Is that something to worry about? Anybody know? I use rmdir -p --ignore-fail-on-non-empty /path/to/dir to remove all non empty dirs on a specific path extensively in scripts and I've never seen wrong behavior on NFS. It will remove all the empty dirs starting at the leaf and then stop without error on the dir that contains other dirs or files. I'm not sure how those switches translate to the C library calls or even it they do at all. -- 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] Behavior of rm, mv, and changes/extra
A -f option on rm and mv might do the trick. Default behavior doesn't change. Add two characters to force the filesystem action. On Wed, Dec 21, 2011 at 3:07 PM, Dmitry Chestnykh dmi...@codingrobots.comwrote: On Wed, 21 Dec 2011 16:52:54 -0500 Jeremy Cowgar wrote: fossil rm should not remove a file it doesn't manage or has changes, just like other SCM systems. In this case, the file in question has changes, as it is brand new, the entire file has changed. Thus, if you were to (in the future) do: $ fossil rm #document_manager.php# File has changes, not removing from disk. Exactly. Mercurial behavior is a bit different -- it doesn't remove it because the file has been marked for adding: ~ $ mkdir hg ~ $ cd hg ~/hg $ hg init ~/hg $ touch file.txt extra.txt ~/hg $ ls extra.txt file.txt ~/hg $ hg add file.txt extra.txt ~/hg $ hg rm extra.txt not removing extra.txt: file has been marked for add (use -f to force removal) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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] bug in user handling
Based on what I've tried so far fossil ui will *always* choose the first user listed in the user table. None of $USER, --user, -U, default-user in global-config or in config will override fossil ui using the first user listed. This is a problem because cloning from a file will preserve the users as listed in the original db. Cloning via http always puts the cloning user first in the table and so fossil ui works as expected. So if user 'bob' creates a fossil and I clone from his db via the filesystem then when I as 'matt' launch the ui the user will be 'bob' by default. If Bob starts up a server from his db and I clone via http then when I run 'fossil ui' the default logged in user will be 'matt'. I guess this was implemented this way for ticket c9e84b5671http://www.sqlite.org/debug1/tktview?name=c9e84b5671(which I don't think makes necessarily makes sense) so the solution is in fixing clone to add the target user as #1 when cloning from a file. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil version 1.21
The changes include: Stop showing the server-code in status outputs - it is no longer used for anything. I've been using the server code extracted with fossil info to uniquely identify repos. Is there a new way? I assume that the server code itself continues to exist? On Tue, Dec 13, 2011 at 7:29 AM, Richard Hipp d...@sqlite.org wrote: Fossil version 1.21 has been packaged and put on the website for convenient download. See http://www.fossil-scm.org/download.html for details including a summary of changes since the previous release. Please let me know if you encounter any problems with this release. Thanks. -- 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] fossil timeline after/before date interpretation
I'm not getting what I would expect from running fossil timeline commands. The example command below should have suppressed the 2011-12-01 entry should it not? chlr11723 fossil timeline after '2011-12-06 00:09:08' -R fossil.fossil === 2011-12-13 === 14:05:36 [489c67ae46] Update the release date on the change log. (user: drh tags: trunk) 13:53:56 [002580c50d] Version 1.21 (user: drh tags: trunk, release, version- 1.21) === 2011-12-06 === 00:09:09 [9c90b0f052] The finfo command and the file browsing pages of the web UI now honor the case-sensitive option and merge filenames that differ only in case as requested. (user: drh tags: trunk) === 2011-12-01 === 16:16:01 [ec5c690e0e] Make allow-symlinks a versionable setting. (user: ben tags: versionable-settings) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] It would be nice if sync collisions failed more gracefully
This is on NFS and with a large check in so it is worst case scenario but still I'm seeing this error when people simultaneously do certain heavy weight actions. Are there any settings that would help here? I've dug though the docs and not seen anything yet. I'll dig though the code tonight but pointers from the experts would be appreciated. FYI, I think these are probably unnecessary failures, however I grant that is may be tough to differentiate from real issues such as db not readable. I think fossil could possibly do a couple things here: 1. Interleave sync actions 2. On failure in sync tell the user that the db is probably busy and try again in a few minutes. [830] fossil update Autosync: file:///blah/blah.fossil Bytes Cards Artifacts Deltas Sent:6945146 0 0 Error: Database error: database is locked DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private) Received: 118 1 0 0 Total network traffic: 3842 bytes sent, 871 bytes received fossil: Autosync failed -- updated-to: 9012cff7d15010018d2fdd73375d198b27116844 2011-10-18 22:33:49 UTC tags: trunk comment: initial empty check-in (user: blah) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] It would be nice if sync collisions failed more gracefully
On Wed, Dec 7, 2011 at 10:38 PM, Nolan Darilek no...@thewordnerd.infowrote: Maybe Fossil could recommend a WAL rebuild command in these instances? Then at least the user has some direction in which to go. At the very least it could output that for relaying to the server administrator. I wasn't clear in my message, these are being served directly by file access, not http and via NFS from multiple hosts. I don't think wal is a safe option. On 12/07/2011 07:48 PM, Richard Hipp wrote: On Wed, Dec 7, 2011 at 7:15 PM, Matt Welland estifo...@gmail.com wrote: This is on NFS and with a large check in so it is worst case scenario but still I'm seeing this error when people simultaneously do certain heavy weight actions. Are there any settings that would help here? I've dug though the docs and not seen anything yet. I'll dig though the code tonight but pointers from the experts would be appreciated. Setting WAL mode on the database will help a lot. However, WAL might not work on NFS. Are all server instances running on the same machine? If so, then you might be able to get WAL to work. I suppose you could try. Do this: fossil rebuild -wal -pagesize 8192 REPO Then see if that helps. FWIW, the Fossil and SQLite repositories take a pretty heavy load without problems and they are both running on the same 1/24th slice VM. They do both use WAL. But they also both use a local disk, not NFS. FYI, I think these are probably unnecessary failures, however I grant that is may be tough to differentiate from real issues such as db not readable. I think fossil could possibly do a couple things here: 1. Interleave sync actions 2. On failure in sync tell the user that the db is probably busy and try again in a few minutes. [830] fossil update Autosync: file:///blah/blah.fossil Bytes Cards Artifacts Deltas Sent:6945146 0 0 Error: Database error: database is locked DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private) Received: 118 1 0 0 Total network traffic: 3842 bytes sent, 871 bytes received fossil: Autosync failed -- updated-to: 9012cff7d15010018d2fdd73375d198b27116844 2011-10-18 22:33:49 UTC tags: trunk comment: initial empty check-in (user: blah) ___ 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 listfossil-users@lists.fossil-scm.orghttp://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] FYI - fossil on n900 works great. Using as sync for zim
Just in case it piques anyones interest, I'm using fossil on my n900 phone to sync zim data to from my desktop and netbook. I like the fit between zim and the Getting Things Done methodology ( http://zim-wiki.org/manual/Usage/Getting_Things_Done.html). I just installed scratchbox (aprox 1/2 hr) and thanks to no dependencies fossil compiled effortlessly. The fossil ui works perfectly and performance is fast enough. My checkout is 16M, the fossil db is 250M (data goes back to 1992). Now what'd be really cool would be a melding of fossil and zim features - there is a lot of overlap. Dreams are cheap :) And for a complete OT paragraph: If you are not following the dotfiles discussion please vote don't care in the poll at http://www.easypolls.net/poll.html?p=4eda64df4fb7b0e46a6feea2 Cheers, Matt -=- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] hidden files on linux support?
Perhaps you want: fossil add --dotfiles . On Fri, Dec 2, 2011 at 11:41 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Dec 2, 2011 at 7:36 PM, Oliver Friedrich beowul...@gmx.de wrote: i'm testing out fossil for my source, found an interesting issue. Checking in files and folders leaves out hidden files, on linux starting with a .. How can I get fossil to check those files in? Unix doesn't actually have hidden files per se - the _convention_ of a preceeding dot is supported by many tools, though. One of those is shell wildcards, which do NOT match a dot character. Try: fossil add .[a-zA-Z]* for example, and you'll get the behaviour you want. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] hidden files on linux support?
On Fri, Dec 2, 2011 at 4:03 PM, Eric e...@deptj.eu wrote: On Fri, December 2, 2011 7:26 pm, Stephan Beal wrote: On Fri, Dec 2, 2011 at 8:17 PM, Eric e...@deptj.eu wrote: Why on earth would you want to? I know others have offered suggestions and explanations for how to do it, but I would never have a dotfile (or a symlink for that matter) in a repository, so I'm really asking about the use-case. Think .gitignore and friends. Some tools support files like that for holding various metadata (some non-git tools support .gitignore). http://gitready.com/beginner/2009/01/19/ignoring-files.html Oh, I know about those. But they are one of 1) needed at build or install time, in which case the build and install scripts create them 2) part of my common development environment, in which case they are not part of what I am developing and do not belong in its repository Do I detect a hint of judgment in your post Eric? Items 1. and 2. are true in your world perhaps but certainly often not in mine. I lost an hour of my time because fossil silently ignored dot files that are a required critical part of a process that I moved from an ancient SCM into fossil. Personally I prefer my tools to let me know if i say add and they choose not to do so however the --dotfiles switch suffices. There are a few interesting arenas where source is not C, nor any other language you are likely to deal with as a normal programmer and yet these arenas can make good use of a tool like fossil and some even pay pretty dang good and maybe even deserve a bit of respect :) 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] Quickref available for fossil
Thanks all for the feedback. Given the goal of getting everything onto a two-sided Letter sized sheet of paper this one quick ref will always be a bit of a compromise but hopefully still useful. I've incorporated some of the feedback given thus far: 1. Added diff -y 2. Fixed some typos 3. Added qualification that this quickref is primarily for Unix/Linux (maybe a Dos/Windows specific one can be created also?) 4. Added the --branch method for merge 5. slightly re-worded some sections, added hint that delta == changes Regarding keeping up with the latest fossil, with five different machines/environments to keep up to date and in sync I will only use officially released binaries for the foreseeable future. However I do watch the mailing list for updates. I think the released version probably does have the side-by-side diffs but I've fallen behind on updating all machines. Note on the safe and unambiguous move. Fossil may want to use rsync as a template for move/copy behavior. With rsync you can lock down the meaning of a directory copy by using a trailing slash: ;; ambiguous depending on whether dirb exists or not rsync -avz dira dirb ;; unambigously puts contents from dira into dirb (exact behavior as no trailing slashes when dirb does not exist): rsync -avz dira/ dirb/ Note on ssh:// URL. I knew that ssh access did not work with fsecure but I just tested it and can't get it to work with openssh. If someone can confirm that using ssh as a transport mechanism is working for them and provide me with an example URL I'd appreciate it. Thanks, Matt -=- On Fri, Nov 25, 2011 at 1:50 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Nov 25, 2011 at 6:21 AM, Matt Welland estifo...@gmail.com wrote: I don't have -y documented in my current version of fossil and assume it isn't there. As soon as I've learned what it is I'll look at adding it. The -y option (side-by-side diff) is a new feature since version 1.20. It seems to me like I've been using it forever, so I guess that means its about time to do a new release, huh? Anyway, I always do: fossil diff -y | open -f prior to check-in to see side-by-side differences. The open -f part works on a mac. But it is so useful that I have my own hack of an implementation for linux as well. Note that the tip of trunk on Fossil is almost always ready to use and in active use by me. The version of Fossil running the Fossil website is usually close to tip-of-trunk. -- 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] A couple thoughts/suggested future enhancements for fossil, ui security, move and ssh access
fossil ui == problem: on a shared machine it is possible to accidentally browse someones already-running ui session possible solutions 1. only the first login is passwordless, subsequent logins require a password 2. a random key is passed to the browser in the URL, only with that key is the session accessible without a login 3. use named pipes, secure and should be possible on both Windows and Linux (but can a browser access as bidirectional?) fossil mv === From my comments in another thread, Fossil may want to use rsync as a template for move behavior. With rsync you can lock down the meaning of a directory copy by using a trailing slash: ;; ambiguous depending on whether dirb exists or not rsync -avz dira dirb ;; unambigously puts contents from dira into dirb (exact behavior as no trailing slashes when dirb does not exist): rsync -avz dira/ dirb/ sync via ssh = From my comments in another thread: I knew that ssh access did not work with fsecure but I just tested it and can't get it to work with openssh. If someone can confirm that using ssh as a transport mechanism is working for them and provide me with an example URL and what they use for ssh-command I'd appreciate it. Also, I was unable to set the ssh-command in the ui - but it does work from the command line. Lastly, the ssh URL - I'm not familiar with using // to make the path relative to home. Rsync and scp both use a : to separate the host from the path and then a ~ works to refer to home. Example: rsync -avz matt@hermes:~/.zshrc ~/ scp matt@hermes:~/.zshrc ~/ Thanks, Matt -=- ___ fossil-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 couple thoughts/suggested future enhancements for fossil, ui security, move and ssh access
Regarding the use of ftp as a model for URLs - seems like a poor choice to me but whatever works is fine. I didn't find the /// in any of the rfc's for ftp - maybe it is a windowsism? Anyhow, passwordless ssh works fine for me but I've tried every combination I can think of and I always get this: matt@zeus ~/data/mattswork % fossil sync ssh://hermes///home/matt/fossils/mattswork.fossil ssh -e none -T hermes fossil: ssh connection failed: [Welcome to Ubuntu 11.10 (GNU/Linux 2.6.38-11-generic i686) * Documentation: https://help.ubuntu.com/ 0 packages can be updated. 0 updates are security updates.] ===detailed transcript=== ssh -v -e none -T hermes OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to hermes [192.168.1.9] port 22. debug1: Connection established. debug1: identity file /home/matt/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/matt/.ssh/id_rsa-cert type -1 debug1: identity file /home/matt/.ssh/id_dsa type -1 debug1: identity file /home/matt/.ssh/id_dsa-cert type -1 debug1: identity file /home/matt/.ssh/id_ecdsa type -1 debug1: identity file /home/matt/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-7ubuntu1 debug1: match: OpenSSH_5.8p1 Debian-7ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA blah blah debug1: Host 'hermes' is known and matches the RSA host key. debug1: Found key in /home/matt/.ssh/known_hosts:3 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/matt/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). Authenticated to hermes ([192.168.1.9]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessi...@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 fossil: ssh connection failed: [Welcome to Ubuntu 11.10 (GNU/Linux 2.6.38-11-generic i686) * Documentation: https://help.ubuntu.com/ 0 packages can be updated. 0 updates are security updates.] matt@zeus ~/data/mattswork % debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2632, received 2280 bytes, in 0.3 seconds Bytes per second: sent 7697.3, received 6667.9 debug1: Exit status 0 end transcript=== On Fri, Nov 25, 2011 at 11:44 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Fri, Nov 25, 2011 at 11:17:20AM -0700, Matt Welland wrote: sync via ssh = From my comments in another thread: I knew that ssh access did not work with fsecure but I just tested it and can't get it to work with openssh. If someone can confirm that using ssh as a transport mechanism is working for them and provide me with an example URL and what they use for ssh-command I'd appreciate it. Also, I was unable to set the ssh-command in the ui - but it does work from the command line. Works fine with the default settings. URL is e.g. ssh://joerg@ip//path-from-home (and /// for absolute urls, like ftp). Joerg ___ 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] Quickref available for fossil
I'm teaching a class on using fossil next week and put together a quick ref sheet to help folks get going. I haven't seen any other quick ref sheets for fossil so maybe this will be of use to others. PDF: http://www.kiatoa.com/cgi-bin/fossils/opensrc/doc/tip/docs/fossil-quickref.pdf Opendoc: http://www.kiatoa.com/cgi-bin/fossils/opensrc/doc/tip/docs/fossil-quickref.odt Feedback, corrections, suggestions all much appreciated. Cheers, Matt -=- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Cloning, syncing via ssh appears to hang...
I'm on Linux and commands such as the following appear to hang: fossil clone ssh://u...@host.domain.tld/path/repo.fossil repo.fossil I have ssh with keys (passwordless login) working fine. How to debug this? fossil version This is fossil version 1.19 [6517b5c857] 2011-09-01 18:25:19 UTC ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Cloning, syncing via ssh appears to hang...
On Mon, Nov 7, 2011 at 9:21 PM, Eduardo Tongson propol...@gmail.com wrote: On Tue, Nov 8, 2011 at 4:00 AM, Matt Welland estifo...@gmail.com wrote: I'm on Linux and commands such as the following appear to hang: fossil clone ssh://u...@host.domain.tld/path/repo.fossil repo.fossil I have ssh with keys (passwordless login) working fine. How to debug this? fossil version This is fossil version 1.19 [6517b5c857] 2011-09-01 18:25:19 UTC Adding -v to the ssh command is a good start. Set it with `fossil settings ssh-command` Here is what I get: debug: SshConfig/sshconfig.c:3116/ssh2_parse_config_ext: Metaconfig parsing stopped at line 3. debug: SshConfig/sshconfig.c:3417/ssh_config_read_file_ext: Read 4 params from config file. debug: SshUnixUserFiles/sshunixuserfiles.c:409/ssh_read_client_configs: Found user config file '/path/to/my/home/dir/.ssh2/ssh2_config' debug: SshConfig/sshconfig.c:3116/ssh2_parse_config_ext: Metaconfig parsing stopped at line 2. This is fsecure ssh (I think?) ssh -h ssh: Reflection for Secure IT 6.1.2.1 (build 3005) on x86_64-suse-linux-gnu (64-bit) Good luck. ___ 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 Repository Does Not Exist Error
I usually open the _FOSSIL_ file with sqlite3 and update the pointer to the repo db. A repodb reset command or some such would be nice to have. matt@hermes sqlite3 _FOSSIL_ ~/data/opensrc SQLite version 3.7.5 Enter .help for instructions Enter SQL statements terminated with a ; sqlite update vvar set value='/home/matt/fossils/mattsmisc.fossil' where name='repository'; On Fri, Oct 28, 2011 at 5:36 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 28 Oct 2011 13:56:21 +0200 Stephan Beal sgb...@googlemail.com wrote: Or if you DO have uncommitted changes you can also try: rm _FOSSIL_ Dangerous if you have stashed changes ;-) Aha - THAT explains why i lost my stash the last time i did that ... ;) For the record (more for the original poster to read), these things are documented in [1]. 1. http://www.sqlite.org/debug1/doc/trunk/www/tech_overview.wiki ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Creating new branch/repository problems
On Sun, Oct 23, 2011 at 12:17 PM, Jared Harder jared.har...@gmail.comwrote: @Matt: I followed the directions and eventually started up a second server. I needed to use fossil server instead because I couldn't access the fossil ui interface from external machines. The README file I edited showed up in the new branch with the changes applied. So perhaps it works because of the changes I made as per Richard's instructions? If that's the case, I should be able to create new branches in my existing repository? Also, how can I have other users select the appropriate branch to check in to? Is there a bit of a walkthrough explaining how to use branches from within Fossil? If the _FOSSIL_ with repository set to '/home/drh/sqlite/fossil.fossil' was up-directory from where you executed the steps then yes, without deleting that file I think you would have seen the same error again. For example in the example tree drawn below the _FOSSIL_ file in dir1 will cause you problems if you attempted to open your repo in dir4. This is generally true - do not open a fossil inside another fossil controlled area unless you know exactly what you are doing. -- dir1 |-- dir2 | `-- dir4 | `-- _FOSSIL_ |-- dir3 | `-- dir4 `-- _FOSSIL Now all your users need to do it clone and open your new repo and then do: fossil co yourbranch Where yourbranch is the name of the branch to be worked on. I couldn't find any simple, step by step, branching and merging tutorial for fossil but the following will get you there with a little reading: Read Jim Schimpf's excellent book on fossil, the free pdf is here: http://www.fossil-scm.org/schimpf-book/doc/tip/fossilbook.pdf More detail about branching/forking is available on the fossil wiki: http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki Matt -=- @Richard: Alright, I've deleted that _FOSSIL_ file. Should I bother getting the newest source and rebuilding, or should I be safe to carry on? Thanks! Jared On Fri, Oct 21, 2011 at 18:48, Richard Hipp d...@sqlite.org wrote: On Fri, Oct 21, 2011 at 7:34 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Oct 20, 2011 at 8:01 PM, Jared Harder jared.har...@gmail.comwrote: No matter what command I try, the error message is always the same: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil Very curious. The /home/drh/sqlite/fossil.fossil pathname is the location of the Fossil repository for Fossil on a machine that I was using as my desktop up until about 2 months ago. So I thought perhaps I had used that name in an example script somewhere. But grep is not finding it. And that pathname is not found anywhere (that I can find) in the canonical Fossil repository on http://www.fossil-scm.org/. I'm very eager to learn how Jared got a checkout that thinks its repository is located at /home/drh/sqlite/fossil.fossil. Joe Mistachkin solved this mystery. The source tarballs from the download page were built incorrectly - they included the _FOSSIL_ file from my development folder. And that _FOSSIL_ file points to the repository on /home/drh/sqlite/fossil.fossil. Apparently, Jared built from the source tarball. I've fixed the most recent tarball and deleted all the prior ones. (Source tarballs can still be obtained directly from Fossil using the /tarball web method, of course.) Jared: You need to find the _FOSSIL_ file in the source directory and delete it. Can you give us more information about where your repository came from, Jared? -- D. Richard Hipp d...@sqlite.org -- 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
