Thus said Richard Hipp on Sat, 10 Aug 2013 20:45:31 -0400:
(1) Put all of the Fossil repositories you want to share in a single
directory, say /home/fossil/repos. Make sure all repository files
are named using the *.fossil pattern. (Technically, you can scatter
the repositories out
Thus said Richard Hipp on Sat, 10 Aug 2013 20:45:31 -0400:
* Users will have to log into each repository separately, by default.
However, if you put multiple repos together into a login group, then
logging into one repo logs them into all other repos of the login
group where they have
Thus said Chad Perrin on Sat, 10 Aug 2013 20:03:58 -0600:
Maybe I can use it for some work done strictly within the network,
if there's no chance (more than usual) that it'll screw up the
repositories I'm using. If there is some increased chance of that, I
might set up some toy
Thus said Richard Hipp on Sat, 10 Aug 2013 20:45:31 -0400:
(2) Run fossil server -port /home/fossil/repos
This too is also amazing functionality! Furthermore, apparently ``fossil
http'' also handles a directory! This would have saved me a lot of time
had I known about it earlier. Guess I
Thus said Chad Perrin on Sat, 10 Aug 2013 20:21:46 -0600:
Why is naming them all foo.fossil important? Is that a hardcoded
extension expectation in the Fossil SCM sources that ensure the server
command will recognize the files -- and is it the only such extension
option for this purpose?
Hello,
After having recently discovered the single sign-on functionality
provided by the Login Groups configuration, I've started experimenting
with it. I must be doing something wrong because it doesn't seem to
work:
I started a fossil server on port serving fossils out of
Thus said Andy Bradford on 10 Aug 2013 21:54:59 -0600:
After having recently discovered the single sign-on functionality
provided by the Login Groups configuration, I've started experimenting
with it. I must be doing something wrong because it doesn't seem to
work
Ok, I found out
Thus said Chad Perrin on Sat, 10 Aug 2013 22:47:11 -0600:
Thanks for the answers/confirmations. I hope I'm not being tedious
asking all these questions -- I just want to be absolutely sure I'm
not misunderstanding anything when the security of my server depends
on some of these
Thus said Chad Perrin on Sat, 10 Aug 2013 20:07:41 -0600:
And then they can clone from there:
fossil clone http://user@127.0.0.1:/project
Thank you. This looks like it will probably suit our needs quite well
for the time being. I'll investigate further on my own at this point,
Thus said Richard Hipp on Mon, 05 Aug 2013 19:42:12 -0400:
That's the way it used to work. I think Andy's changes fix it so
that it doesn't work that way any more. I'm disappointed too, and
would like to find a solution that works both ways.
Ok, I've reimplemented the original
Thus said j. van den hoff on Thu, 08 Aug 2013 09:31:28 +0200:
1.in `orig.fossil'the(sole) `setup'user isme
(current_login_name), which is as it should be. (as an aside: the help
text does speak of `admin' user, but actually its the `setup' user
(and a `admin'
Thus said j. van den hoff on Thu, 08 Aug 2013 08:31:04 +0200:
`finfo -b' is supposed to produce one-line abbreviations for all
commits but in fact introduces spurious line breaks which put a single
trailing word (or some chars) on the next line.
This would appear to be a bug in the
Hello,
As I was trying to setup an environment that used REMOTE_USER, I noticed
that cloning failed. So I turned on --httptrace and found this output:
# cgi: REMOTE_USER = [guest]
# login: [guest] with capabilities [v]
Which looks alright (according to the documentation a user with 'v'
Hello,
Last week I sent out an email regarding the new SSH changes, which I
believe are ready to go:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12579.html
I have been using it and it feels stable. There has only been one change
since then (cleans up output during
Thus said Richard Hipp on Mon, 05 Aug 2013 16:21:05 -0400:
I just tried it, and it is different, isn't it. :-|. Let me mess
around some and see if I can live with the change. Apparently, I'll
need to get real familiar with --ssh-fossil-user
Yes, it's a bit different becuase now
Thus said Andy Bradford on 05 Aug 2013 14:40:08 -0600:
Addtionally, it is now possible to use SSH keys and Force Commands to
restrict the SSH account to doing Fossil only activities.
s/possible/easier/
It was always possible to write a wrapper script, but it's much easier
if fossil
Thus said Richard Hipp on Mon, 05 Aug 2013 19:42:12 -0400:
Once I have my ssh key entered I should be able to do all operations
(clone, sync, commit etc.) without entering my password but the
remote fossil knows who I am.
That's the way it used to work. I think Andy's changes fix
Thus said Andy Bradford on 05 Aug 2013 22:42:44 -0600:
It would be better if I didn't have to rely on a script for this,
which is why I thought a new fossil subcommand would be useful. This
would mean all I have to put into my command= is something like:
Ok, scratch that. I've already
Thus said Stephan Beal on Sat, 03 Aug 2013 18:23:46 +0200:
http://fossil-scm.org/index.html/info/73135ec22a
Wow that was quick!
I suppose an alternate approach could have been to modify ``fossil
timeline'' to accept a TAG to restrict its search to just those
artifacts with the
Thus said Stephan Beal on Sat, 03 Aug 2013 19:48:07 +0200:
Ah, right, that's the www interface and you want the CLI... that
one's a bit more difficult, so i won't be patching that tonight.
The timeline is probably the most complicated single piece of
functionality in the
Thus said Gour on Sat, 03 Aug 2013 21:25:01 +0200:
Moreover, iirc, there was also another request to be able to push
distinct branches which also, afaict, is not implemented.
Both features are something which one takes for granted in every other
DVCS (bzr, darcs, git, hg...)
I
Thus said Jan Nijtmans on Thu, 01 Aug 2013 10:03:36 +0200:
Thanks for your testing and your feedback! It's on trunk now. I used
merge --integrate when doing that.
One other thing I noticed is that when merging in a forked trunk with
--integrate, it will explicitly close the trunk, which
Thus said Clark Christensen on Wed, 31 Jul 2013 10:01:58 -0700:
dir /b/f/s testfile.txt
D:\var\fossil\junk\first\testfile.txt
D:\var\fossil\junk\second\testfile.txt
fossil mv first/testfile.txt second/testfile.txt
RENAME first/testfile.txt second/testfile.txt
Did you forget to mv the
Thus said Jan Nijtmans on Tue, 30 Jul 2013 10:11:52 +0100:
http://www.fossil-scm.org/index.html/info/2015bbd55d
Still no objections, anyone? I think it's ready to be integrated into
trunk (using merge --integrate, of course), but another round of
evaluation never hurts!
It might be
Thus said Andy Bradford on 31 Jul 2013 20:37:19 -0600:
It might be a little late in the game, but why is it called integrate?
Maybe I missed the discussion about why it is called that---I'll scour
the archives.
After reading the archives it does appear that --integrate, while not
quite
Thus said David Mason on Thu, 25 Jul 2013 18:16:08 -0400:
command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ...
where the name after gate defines the fossil user that this
represents, and the ... are the public keys from the particular users.
Should this instead
Thus said Alan Barrett on Mon, 29 Jul 2013 08:29:37 +0200:
Regardless of whether this is a good idea or not, please do not call it
fossil gate. Please give it a name that alerts the user to the fact
that it's very closely tied to ssh.
Understood. At this point, it is really just a concept
Hello,
Many thanks to those who have provided feedback and suggestions for how
to improve the SSH transport for ssh:// URLs.
Is there anything else left to be done (specifically for what is
required to be directly in Fossil) regarding the SSH transport changes?
I've tested it with a
Thus said Eric Rubin-Smith on Sat, 27 Jul 2013 16:31:46 -0400:
I tested this basic claim and do not believe it holds:
[monk:~] $ head -c $(echo 392*1024*1024|bc) /dev/zero foo
[monk:~] $ du -sch foo
392Mfoo
392Mtotal
[monk:~] $ time md5sum foo
c6d8f8fc5c75fd6ecceb4edf42f3ac4d
Thus said MaxJarek on Wed, 24 Jul 2013 11:22:52 +0200:
Fossil don't force https login. Any hints?
Try setting https-login in your global config prior to cloning:
fossil settings https-login on
Andy
--
TAI64 timestamp: 400051f445b1
___
Hello,
When cloning a fossil that has last-sync-pw in the config (e.g. a fossil
that was cloned with http://user:passwd@remote/) into a file:// URL, it
also copies the last-sync-pw into the new file. Is this intentional?
Obviously the last-sync-pw will not be used because the new fossil
Thus said henk harmsen on Fri, 26 Jul 2013 10:38:50 +0200:
The problem that I am facing is that the Debian path starts with
/media/usb/mydir,
whereas in Windows that is G:\mydir.
So, fossil status gives :
current directory is not within an open checkout.
Is there a workaround for this?
Thus said Edward Berner on Fri, 26 Jul 2013 16:49:45 -0700:
So... try keeping your repository one directory above your checkout
and opening it as fossil open ../repo.fossil and see if both
platforms are happy with that.
This is what one gets using relative paths:
$ fossil open
Thus said Stephan Beal on Wed, 24 Jul 2013 16:51:07 +0200:
This probably isn't what you want to do, but i think you could
add anonymous support by piping the /json/anonymousPassword and
/json/login calls through to manage the two-step authentication
process for anonymous
Thus said Martin Gagnon on Wed, 24 Jul 2013 20:44:05 -0400:
I tried this new version today. There is an improvement in sync
terminal output. But it seems that now, if I have a user in the URL
and a -l user argument, the user from the URL is used for the fossil
authentifcation. (It
Thus said Martin Gagnon on Wed, 24 Jul 2013 20:44:05 -0400:
But it seems that now, if I have a user in the URL and a -l
user argument, the user from the URL is used for the fossil
authentifcation.
Thanks for pointing it out:
Thus said Martin Gagnon on Tue, 23 Jul 2013 16:57:46 -0400:
the -e none argument to ssh is removed when __MINGW32__ is defined.
Is there a reason for that ? On my windows setup, I have mingw and I
use openssh that come with msys.
I'm not sure why it would be this way. If all versions of
Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400:
/usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080
--baseurl http://localhost:10080/
Try removing the --baseurl option.
It works for me when I do:
fossil server /tmp/test.fossil
ssh -L
Thus said Andy Bradford on 23 Jul 2013 20:22:37 -0600:
fossil server /tmp/test.fossil
Of course I meant:
fossil server -P 10080 /tmp/test.fossil
ssh -L 10080:localhost:10080 remote
Cheers,
Andy
--
TAI64 timestamp: 400051ef3c17
___
fossil
Thus said Rene on Sun, 21 Jul 2013 00:00:01 +0200:
A forced command is in place and it can only be fossil http.This will
check if it is started via ssh and then look in the environment to see
if the request was fossil gate myotherdb.
For now, I think I will abandon the idea that this type of
Thus said Matt Welland on Sun, 21 Jul 2013 22:16:42 -0700:
The ssh key is being used to give access only to the fossil file and
yes, the access list would map ssh keys (thus users) to fossils.
Just for clarification... access list would map an SSH key user
to fossils, but not
Thus said Martin Gagnon on Wed, 17 Jul 2013 08:04:10 -0400:
I propose to add a kind of -l|--login option to the clone command, so
when the username@ is present but don't match the repo username, we
could specify repo username with -l.
After giving this additional thought, I went ahead
Thus said Stephan Beal on Sat, 20 Jul 2013 18:48:44 +0200:
http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek
try resizing your browser in that view.
Looks like it works great.
Just one observation; I find that the alternating row colors are
Hello,
I've been working on a simple fossil command that will integrate with
SSH accounts where SSH keys are in use and wonder if there is a formal
process for coming up with new subcommand names? Here is what I have at
the moment:
$ fossil help gate
Usage: fossil gate ?FILENAME?
Thus said Rene on Sun, 21 Jul 2013 00:00:01 +0200:
A forced command is in place and it can only be fossil http.This will
check if it is started via ssh and then look in the environment to see
if the request was fossil gate myotherdb.
what are you trying to archive?
I'm trying to
Thus said Martin Gagnon on Wed, 17 Jul 2013 08:04:10 -0400:
I propose to add a kind of -l|--login option to the clone command, so
when the username@ is present but don't match the repo username, we
could specify repo username with -l.
While I do like this idea, at first glance it
Thus said Matt Welland on Thu, 18 Jul 2013 07:24:20 -0700:
I see the ssh implementation as a possible stepping stone to something
along the lines of gitolite for fossil.
I was not familiar with gitolite, however, after having looked at the
website, this is very similar to how I had
Hello,
After giving a little though to handling shared SSH accounts, it might
be as simple as the following change:
https://www.fossil-scm.org/index.html/info/7a10b79a2c
Basically, if the specified SSH command already has an '@' in it, don't
use the username@host found in the URL, but use
Thus said Rene on Sun, 14 Jul 2013 21:34:06 +0200:
I looked at andy's patch, but I cannot make a definite conclusion how
it works when multiple users share one ssh account service (fossil).
I had given some thought to this particular use case, but it is outside
the scope of the original SSH
Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200:
I would prefer to not have that option. test-http is for testing a new
transport method. If you give someone read acces to your ssh repo then
test-http circumvents that. In fact test-htp makes you while connected
setup user
I agree with you
Folks,
As I mentioned before, I've been attempting some modifications to the
fossil SSH URL handling. I'm at a point where I could use some feedback
regarding the previous method for handling SSH.
Originally, fossil would fork an SSH connection and then communicate
with the remote shell
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400:
Sorry, *my* mistake.. I didn't notice the new version of the patch on
latest Andy Bradford email. My test was made with the previous patch.
Not a problem. I should probably setup a fossil clone that can be
accessed, rather
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400:
Work fine now.. sorry for the noise..
Speaking of noise, time to add a little more (because my original email
wasn't quite long enough).
The new options that I've added are not yet fully documented in the
usage/help (not having
Thus said Rene on Sun, 30 Jun 2013 16:07:44 +0200:
It could be an alternative way. But the urlShell seems to be much
easier!
Thanks, I actually looked at urlShell, but it didn't seem right, or was
confusing, or both.
I've actually made some progress in getting the fossil client
Thus said Martin Gagnon on Mon, 01 Jul 2013 09:08:54 -0400:
Have you try with server running more recent version ? I remember
there was a patch somewhere between version 1.24 and 1.25 that was
forcing full right when syncing using ssh://.
I've tried with both 1.22 and 1.26. Here it
Thus said Richard Hipp on Mon, 01 Jul 2013 17:23:58 -0400:
When you run the fossil http command, the user identified by each
HTTP request is used. However, ssh does not run fossil http, it uses
fossil test-http instead (unless Andy has changed that in his local
copy). And fossil
Thus said Andy Bradford on 29 Jun 2013 20:34:07 -0600:
So it seems to think that the server didn't respond, but it surely
looks like it did. Will this approach even work?
Ok, the problem was that the connection was closed (due to missing
keep-alive, so SSH closed connection
Hello,
I'm trying to configure a secure fossil hosted repository using fossil
http. I've gone through various configurations, but each one has
different problems. I would prefer to use SSH keys, but apparently
fossil's client design doesn't lend itself well to ForceCommand SSH
Thus said Andy Bradford on 29 Jun 2013 13:57:39 -0600:
execargs = fossil http --baseurl https://fossil:1973/ /tmp/test.fossil
Ignore the typo, I did have it correctly set to:
execargs = fossil http --baseurl https://fossil:1621/ /tmp/test.fossil
Don't let this distract from the original
Thus said Andy Bradford on 29 Jun 2013 13:57:39 -0600:
html
pRedirect to Location: https://fossil:1621//login?g=/setup_config
/p
/html
Which I assume my browser tries to fetch, but it clearly fails because
it returns to the Home page which wants me to click setup/config.
I failed
Thus said Richard Hipp on Sat, 29 Jun 2013 16:10:52 -0400:
Dunno if your problems are a Fossil bug or not. Please do
note, however, that you can access Fossil itself over https
(https://www.fossil-scm.org/) and the Fossil website is just a running
instance of Fossil,
Thus said Andy Bradford on 29 Jun 2013 14:24:21 -0600:
Let me know if there's any additional information that would help.
Not sure if this will help, but I setup two separate repositories using
the two methods I mentioned:
https://fossil1.bradfords.org:1231
Username: _fossil
Password: ded6a3
Thus said Richard Hipp on Sat, 29 Jun 2013 16:47:55 -0400:
Please bring up fossil ui locally, go to Admin/Settings and enable
test_env for me.
This is now enabled, however, I believe Francis was able to point out
the missing configuration option. I had apparently misunderstood the
Thus said Francis Daly on Sat, 29 Jun 2013 21:41:59 +0100:
[I thought I had already responded to you but I cannot find the
response. So if this is a repeat, I apologize. This does appear to be
the problem.]
This says run fossil http, and it should assume that any generated
Hello,
Next hurdle. SSL or SSH on Windows.
I just discovered that fossil.exe does not have SSL support, so that
kind of presents a hurdle. By the way, it works nicely in a chroot with
stunnel and SSL client certificates on an OpenBSD server.
So, now on to SSH...
I'm trying to setup a
Thus said Andy Bradford on 29 Jun 2013 18:19:48 -0600:
As can be seen, when my SSH key is used, it will be forced into fossil
http mode, but the client crashes.
I just found the following:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02963.html
I don't know what ever
Thus said Andy Bradford on 29 Jun 2013 18:19:48 -0600:
Is there some trick I need to tell the client that it already has an
open fossil http server waiting to be used on stdin/stdout and to just
start talking HTTP?
Ok, so I got impatient and cracked open the source. It looks like
Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400:
I also wonder if it effected the choice of whether to use fossil or
not for various projects. I know that, personally, there are a few
places that I've wanted to START with versioned documentation, and
would have
Thus said Konstantin Khomoutov on Tue, 14 May 2013 07:40:41 +0400:
That is, it's backwards: you first do some work, then decide to commit
and decide this commit should start its own branch rather than
continuing the current one, so you create that new branch while
committing.
901 - 969 of 969 matches
Mail list logo
