Re: [fossil-users] RFC: what do we do with the JSON docs?

[David Bovill]

On 27 March 2012 17:35, Stephan Beal  wrote:

> The considerations which have come to mind so far:
>
> - i would prefer to keep it in wiki form, as opposed to embedded docs,
> because i often write docs from arbitrary locations.
>

Yes

-  would prefer to not use fossil's wiki markup (i find it too verbose -
> too close to HTML), but Google Code (it's what i know and like best). i
> could _possibly_ be convinced to use Markdown if there are _compelling_
> arguments for it in this specific context (not in a generic sense). (But
> please don't turn this thread into the re-re-re-visited wiki format debate!)
>

Personally I'd prefer MediWiki markup - as that's where the content is -
but whatever :) Is it possible to include a JavaScript based skin switcher
- that way you could have a choice of markups - given someone writing a
skin with an embedded parser?

- Because of the size of the docs (currently over 50 pages, which would
> need to be split up into many wiki pages) and the frequency at which i tend
> to update docs, i'd prefer to keep them out of the core fossil repo (to
> avoid polluting it, basically), but...
>
> - It might be interesting to kick around the idea of adding
> json.fossil-scm.org (Richard willing) and host the docs from there using
> a custom JSON-based front-end like the one i've started porting my own
> wikis to:
>
>
Yes


> While we could argue forever about the down-side of the non-googlability
> of client-side-rendered wikis, i think it is important that that the
> documentation for the JSON API be served via the JSON API, if for no other
> reason than having it as the canonical demonstration app.
>

Yes - a static dump with links to the live wiki could help?
___
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] push not allowed using ssh://

[Martin Gagnon]

On Thu, Mar 29, 2012 at 12:29 PM, Stephan Beal wrote:

> On Thu, Mar 29, 2012 at 6:08 PM, Martin Gagnon  wrote:
>
>> Latest version from trunk.
>>
>>
> Is it possible that your server has 2 fossil binaries and that the default
> $PATH set via an ssh shell is finding an older one? That has happened to me
> with various apps before.
>
>

That was it, thanks.. my server had a fossil executable with older version
(1.20) the newer version on it was renamed because I'm was trying a
modified version from my own private branch...

Thanks

-- 
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] Fossil reference in DuckDuckGo

[Dmitry Chestnykh]

Just found out that DuckDuckGo search engine have zero-click references 
for Fossil commands:


https://duckduckgo.com/?q=fossil+commit

--
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

Re: [fossil-users] Fwd: Problem with symlinks

[Dmitry Chestnykh]

On 03/29/2012 09:16 PM, Stephan Beal wrote:

On Thu, Mar 29, 2012 at 9:10 PM, Dmitry Chestnykh
mailto:dmi...@codingrobots.com>> wrote:

-  g.allowSymlinks = db_get_boolean("allow- symlinks", 0);
+  g.allowSymlinks = db_get_boolean("allow- symlinks", g.allowSymlinks);


 From main.c:

   memset(&g, 0, sizeof(g));

so the patch would seem to (unless allowSymlinks is set somewhere else)
have the same effect as before?


Yes, it's a leftover from trying various things -- the other line does 
the trick:


+  db_open_config(0);

This would fill "allow-symlinks" from global settings if it's unset in 
repository, if I remember correctly. The patch works, btw :)


--
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

Re: [fossil-users] Fwd: Problem with symlinks

[Stephan Beal]

On Thu, Mar 29, 2012 at 9:10 PM, Dmitry Chestnykh
wrote:

> -  g.allowSymlinks = db_get_boolean("allow-**symlinks", 0);
> +  g.allowSymlinks = db_get_boolean("allow-**symlinks", g.allowSymlinks);
>

>From main.c:

  memset(&g, 0, sizeof(g));

so the patch would seem to (unless allowSymlinks is set somewhere else)
have the same effect as before?

-- 
- 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

Re: [fossil-users] Fwd: Problem with symlinks

[Dmitry Chestnykh]

On 03/28/2012 04:57 PM, Greg Bailey wrote:

I'm still encountering this bug with fossil 1.22. Reproduction steps are
in the original email below. Symbolic links are sometimes being created
as plain files.


OK, I fixed this particular bug, but haven't committed changes to trunk 
yet (the patch is at the bottom of the message), because I think the 
current behavior for the *global* setting "allow-symlinks" is wrong. 
This global setting should be considered only when creating new 
repositories, and it shouldn't affect/override repository setting.


Current behavior (with the fix below):

- When creating a new repository, allow-symlinks for this repository is 
unset (thus "off" by default).


- When opening/checking out a repository, allow-symlinks is read both 
from global settings and repository settings. If it's set to on/off in 
global settings, but is unset in repository settings, global wins.


Why is it so? I think it's wrong, because what the repository says about 
symlinks must be what you get in the checkout, disregarding whatever is 
in your global settings.


So, I propose to always set "allow-symlinks" to [whatever the global 
setting is] for new repositories when creating them instead of leaving 
it unset.




Index: src/db.c
==
--- src/db.c
+++ src/db.c
@@ -932,11 +932,11 @@
   }
   db_open_or_attach(zDbName, "repository");
   g.repositoryOpen = 1;
   g.zRepositoryName = mprintf("%s", zDbName);
   /* Cache "allow-symlinks" option, because we'll need it on every 
stat call */

-  g.allowSymlinks = db_get_boolean("allow-symlinks", 0);
+  g.allowSymlinks = db_get_boolean("allow-symlinks", g.allowSymlinks);
 }

 /*
 ** Flags for the db_find_and_open_repository() function.
 */
@@ -1752,10 +1752,11 @@
 usage("REPOSITORY-FILENAME ?VERSION?");
   }
   if( !allowNested && db_open_local() ){
 fossil_panic("already within an open tree rooted at %s", 
g.zLocalRoot);

   }
+  db_open_config(0);
   file_canonical_name(g.argv[2], &path, 0);
   db_open_repository(blob_str(&path));
   db_init_database("./_FOSSIL_", zLocalSchema, (char*)0);
   db_delete_on_failure("./_FOSSIL_");
   db_open_local();



--
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

Re: [fossil-users] branch switching [was: import of ancient projects]

[Stephan Beal]

On Thu, Mar 29, 2012 at 8:19 PM, mlfconv  wrote:

> Absolutely no problem, thanks! I haven't figured out co since the version
> of Fossil I'm using doesn't seem to list co as
>
a command. [1.22] Are there plans to add co to list of commands?
>

It's an alias for checkout, and aliases apparently don't show up in that
list. See:

[stephan@hamsun:~/cvs/fossil/fossil]$ f help checkout
Usage: f checkout ?VERSION | --latest? ?OPTIONS?
   or: f co ?VERSION | --latest? ?OPTIONS?
...



> Perhaps instead of"The --branch option folowed by a branch name causes the
> new checkin to be placed in the named branch" something like "the --branch
> option followed by branch name causes the new check-in to be placed in a
> newly created branch carrying the name specified by --branch option"
>

[stephan@hamsun:~/cvs/fossil/fossil]$ f help ci
...
The --branch option followed by a branch name causes the new
check-in to be placed in a newly-created branch with the name
passed to the --branch option.

[stephan@hamsun:~/cvs/fossil/fossil]$ f com -m 'minor checkin doc
improvement (suggestion from Marek).'
Autosync:  http://step...@fossil-scm.org
Bytes  Cards  Artifacts Deltas
Sent: 177  2  0  0
Received: 768 17  0  0
Total network traffic: 375 bytes sent, 590 bytes received
New_Version: b6d219b9203d17e1c49b663b21ca5d1f266acd9d
...



> Also"check in to this new branch" could be replaced by "check in to this
> newly created branch"
>

i think that one's splitting hairs. :)


> alternatively perhaps something like
> Fossil commit --branch --basis would be nice where if a branch doesn't
> exist it would create one and if not it would co to that branch.
>

i'll have to defer such a change to someone more familiar with that
particular code :/. i primarily hack on the far outer edges of fossil
(mainly the JSON API), not in the hard parts ;).


-- 
- 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

Re: [fossil-users] branch switching [was: import of ancient projects]

[Themba Fletcher]

On Thu, 2012-03-29 at 19:40 +0200, mlfconv wrote:
> Hi Ron,
> 
> thanks for your advice, will try, right now I'm unable to figure out
> how to switch to a branch or commit into a branch - it seems that if I
> run:
> 
> fossil branch new B 
> fossil add somefile.c
> fossil commit -m"commit" --branch B
> 
> the graph indicator creates 3 separate arrows instead of 2 and it
> looks as if fossil thinks that I'd like to have 2 distinctive branches
> both called B.
> 
> Also creating another branch C actually creates one but when commiting
> another somefile.c, the arrow pointing  from somefile.c tagged 'B'
> would point to somefile.c tagged'C' however another arrow would point
> from trunk to branch 'C' but not from branch'C' to somefile.c tagged
> 'C'. All I'm running are the above mentioned cmds repeatedly and in
> that order.
> 
> thanks,
> 
> Marek
> 

To expand a bit on Stephen Beal's answer (because there are lots of
different ways to use fossil):

I think of fossil checkout (co) as "get me a copy of the contents of the
repo right here, absolutely and without regard to what I happen to be
doing." I tend to use fossil update for almost everything as it seems to
be to be more forgiving of my sloppy work habits:

  tif@whiskey-five:~/Desktop/Projects/ACSS/project$ fossil help update
  Usage: fossil update ?VERSION? ?FILES...?

  Change the version of the current checkout to VERSION.  Any uncommitted
  changes are retained and applied to the new checkout.

  

  The -n or --nochange option causes this command to do a "dry run".  It
  prints out what would have happened but does not actually make any
  changes to the current checkout or the repository.

So if I've changed something but realize it belongs in a different
branch than I happen to have open fossil update lets me change branches
and brings the new changes with it.

If my spidey sense starts tingling I'll do a "fossil update
 -n" to make sure no funny business is about to happen.

So I only ever use fossil checkout immediately after making a new
working directory and doing a fossil open. I had it (fossil co)
overwrite a couple of files early on in my learning curve and I've been
gunshy about using it on a working repo since.

To get what you are looking for above you can do it several ways:

fossil branch new B
fossil update B
fossil add somefile.c
fossil commit -m "commit"

or, more simply:

fossil add somefile.c
fossil commit -m "commit" --branch B

Which is how I tend to work.

In either case fossil status will show your working directory is now
tracking branch B.

The breakdown of the commands you gave (assuming you started in trunk)
is as follows:

> fossil branch new B 
-- just create a branch named B

> fossil add somefile.c
-- add somefile.c to the repo in the currently checked-out branch
(assuming trunk)

> 
> fossil commit -m"commit" --branch B
-- commit changes to a new branch named B

Just a few words that will hopefully help you on your way.

Also -- a bit of unsolicited advice that I wish I had not had to learn
the hard way:

Early on I thought it might be a good idea to structure my projects like
so:

project
 |_ project.fossil
 |_ file1
 |_ dir1 
 |_ etc

It's not. Keep your working repo (assuming you're starting with a single
machine - single repo setup like I did) out of your project directory.
You'll quickly find that you rely on fossil to keep things for you and
that it does a fantastic job, and you may start playing fast and loose
with the command link because, after all, no matter what you do your
files are safe. There's quite a lot of power in being able to act this
way towards a project, but with the repo in the project directory as
above you're always one ill advised wildcard on an rm command away from
losing everything :)


Themba
> 
> 
>  Original Message 
> From：Ron Wilson 
> Time：3/28/2012 19:12
> To：Fossil SCM user's discussion 
> Subject：Re: [fossil-users] import of ancient projects
> 
> 
> On Wed, Mar 28, 2012 at 12:54 PM, mlfconv  wrote:
> > basically i don't want Fossil to perform a merge of A2 and B2 (A is
> the
> > master branch) but insert another file which only acts as a merge
> and is
> > tagged or labeled as merge but no actual merge is performed by
> Fossil, A3 is
> > only inserted instead of merging (A3 actually is a file that merged
> two
> > distinct features from A2 and B2 which is why I want to keep it as
> > historical record instead of doing an actual merge, also B2 evolved
> into B3
> > after "merge" into A3.
> 
> As long as you don't mind that the revision graph will not show any
> indication of a merge, you can just commit A3 as is.
> 
> If you do want the graph to show a merge, you can do a fossil merge,
> then replace the result with your A3 before commiting.
> 
> (As I mentioned, fossil merge does not automatically commit the result
> of a merge. In your case, it would merge changes from B into your
> working copy of A2, leaving the resulting files for you to
> review/edit/replace,

Re: [fossil-users] branch switching [was: import of ancient projects]

[mlfconv]

Hi Stephan,

Absolutely no problem, thanks! I haven't figured out co since the version of 
Fossil I'm using doesn't seem to list co as a command. [1.22] Are there plans 
to add co to list of commands?
Perhaps instead of"The --branch option folowed by a branch name causes the new 
checkin to be placed in the named branch" something like "the --branch option 
followed by branch name causes the new check-in to be placed in a newly created 
branch carrying the name specified by --branch option"

Also"check in to this new branch" could be replaced by "check in to this newly 
created branch" 

alternatively perhaps something like
Fossil commit --branch --basis would be nice where if a branch doesn't exist it 
would create one and if not it would co to that branch.
 
Marek


 Original Message 
From：Stephan Beal 
Time：3/29/2012 19:49
To：Fossil SCM user's discussion 
Subject：Re: [fossil-users] branch switching [was: import of ancient 
projects]

On Thu, Mar 29, 2012 at 7:48 PM, Stephan Beal  wrote:

> so "NEW" is a good hint that it creates the branch.
>

My apologies if that came across sarcastic or stern - that wasn't my
intention.

-- 
- 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] Fwd: Problem with symlinks

[Dmitry Chestnykh]

On 03/28/2012 04:57 PM, Greg Bailey wrote:

I'm still encountering this bug with fossil 1.22. Reproduction steps are
in the original email below. Symbolic links are sometimes being created
as plain files.


Thanks, I reproduced the bug. The reason is that before there's an open 
checkout, "allow-symlinks" option is off -- it's not read from the 
repository or global settings. I'm working on the fix.


--
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

Re: [fossil-users] branch switching [was: import of ancient projects]

[Stephan Beal]

On Thu, Mar 29, 2012 at 7:48 PM, Stephan Beal  wrote:

> so "NEW" is a good hint that it creates the branch.
>

My apologies if that came across sarcastic or stern - that wasn't my
intention.

-- 
- 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

Re: [fossil-users] branch switching [was: import of ancient projects]

[Stephan Beal]

On Thu, Mar 29, 2012 at 7:40 PM, mlfconv  wrote:

> fossil branch new B
>

fossil co B

then:


> fossil add somefile.c
> fossil commit -m"commit"
>

The help says:
--branch NEW-BRANCH-NAME   check in to this new branch

so "NEW" is a good hint that it creates the branch.

Use checkout (co) to switch between branches and the "branch ls" command to
list them.

-- 
- 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

Re: [fossil-users] branch switching [was: import of ancient projects]

[mlfconv]

Hi Ron,

thanks for your advice, will try, right now I'm unable to figure out how to 
switch to a branch or commit into a branch - it seems that if I run:

fossil branch new B 
fossil add somefile.c
fossil commit -m"commit" --branch B

the graph indicator creates 3 separate arrows instead of 2 and it looks as if 
fossil thinks that I'd like to have 2 distinctive branches both called B.

Also creating another branch C actually creates one but when commiting another 
somefile.c, the arrow pointing  from somefile.c tagged 'B' would point to 
somefile.c tagged'C' however another arrow would point from trunk to branch 'C' 
but not from branch'C' to somefile.c tagged 'C'. All I'm running are the above 
mentioned cmds repeatedly and in that order.

thanks,

Marek
 


 Original Message 
From：Ron Wilson 
Time：3/28/2012 19:12
To：Fossil SCM user's discussion 
Subject：Re: [fossil-users] import of ancient projects

On Wed, Mar 28, 2012 at 12:54 PM, mlfconv  wrote:
> basically i don't want Fossil to perform a merge of A2 and B2 (A is the
> master branch) but insert another file which only acts as a merge and is
> tagged or labeled as merge but no actual merge is performed by Fossil, A3 is
> only inserted instead of merging (A3 actually is a file that merged two
> distinct features from A2 and B2 which is why I want to keep it as
> historical record instead of doing an actual merge, also B2 evolved into B3
> after "merge" into A3.

As long as you don't mind that the revision graph will not show any
indication of a merge, you can just commit A3 as is.

If you do want the graph to show a merge, you can do a fossil merge,
then replace the result with your A3 before commiting.

(As I mentioned, fossil merge does not automatically commit the result
of a merge. In your case, it would merge changes from B into your
working copy of A2, leaving the resulting files for you to
review/edit/replace, then you have to do the actual commit.)
___
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] push not allowed using ssh://

[Stephan Beal]

On Thu, Mar 29, 2012 at 6:08 PM, Martin Gagnon  wrote:

> Latest version from trunk.
>
>
Is it possible that your server has 2 fossil binaries and that the default
$PATH set via an ssh shell is finding an older one? That has happened to me
with various apps before.


> I've look at this fix, it look like to affect only cgi mode, right ?  In
> my case, I point to the ".fossil" directly using ssh://. Which should be
> equivalent of using file:// locally I guess.
>

In addition to Richard's previous explanation, a bit of trivia: fossil's
HTML interface is all implemented in terms of CGI mode. Even when running
"fossil server", the server process just sets up the CGI environment and
forks off each request to the CGI handler.

-- 
- 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

Re: [fossil-users] push not allowed using ssh://

[Richard Hipp]

On Thu, Mar 29, 2012 at 12:08 PM, Martin Gagnon  wrote:

>
>> What fossil version are you using?
>>
>>
> Latest version from trunk.
>
> I've look at this fix, it look like to affect only cgi mode, right ?
>

The way ssh:// works is that the local side sends appropriate shell
commands to the far end to start a mini-webserver that interprets HTTP
requests coming over the ssh pipe.  Then then the local side starts sending
the same HTTP requests over the ssh pipe that it would have been sending
over the network if you had used http://.  The far side handles those
requests and sends replies back over to the local end over the same ssh
pipe.

So, right.  The patch "only [e]ffects cgi mode".  Kinda.  But that is the
only "mode" that ssh uses.



>  In my case, I point to the ".fossil" directly using ssh://. Which should
> be equivalent of using file:// locally I guess.
>
> --
> Martin G.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] push not allowed using ssh://

[Martin Gagnon]

On Thu, Mar 29, 2012 at 11:58 AM, Stephan Beal wrote:

> On Thu, Mar 29, 2012 at 5:55 PM, Martin Gagnon  wrote:
>
>> Error: not authorized to write
>> Received: 433  1  0  0
>> Total network traffic: 778 bytes sent, 491 bytes received
>> fossil: Autosync failed
>> ===
>>
>
> IIRC Richard committed a fix for this recently:
>
> http://fossil-scm.org/index.html/info/a928c89cb1
>
> What fossil version are you using?
>
>
Latest version from trunk.

I've look at this fix, it look like to affect only cgi mode, right ?  In my
case, I point to the ".fossil" directly using ssh://. Which should be
equivalent of using file:// locally I guess.

-- 
Martin G.
___
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] push not allowed using ssh://

[Richard Hipp]

On Thu, Mar 29, 2012 at 11:55 AM, Martin Gagnon  wrote:

> Hi list,
>
> I notice that when using ssh:// protocole to clone, even if I have
> read/write access to the fossil file from my ssh account, I cannot push to
> it.
>

What version of Fossil are you running?  Does it include this
patch
?


>
> exemple: (with autosync ON)
> ===
> $ fossil ssh://myhost/somepath/myrep.fossil myrep.fossil
>
> $ mkdir rep
> $ cd rep
> $ fossil open ../myrep.fossil
>
>   
>
> $ fossil commit -m "some messages"
> Autosync:  ssh://myhost/somepath/myrep.fossil
> ssh -e none -T myhost
> Bytes  Cards  Artifacts Deltas
> Sent: 130  1  0  0
> Received: 400  9  0  0
> Total network traffic: 298 bytes sent, 459 bytes received
> Closing SSH tunnel: New_Version: 45c982c33dfaeb2f96095604a3286a19237e9d48
> Autosync:  ssh://myhost/somepath/myrep.fossil
> ssh -e none -T myhost
> Bytes  Cards  Artifacts Deltas
> Sent:1194 14  0  2
> Error: not authorized to write
> Received: 433  1  0  0
> Total network traffic: 778 bytes sent, 491 bytes received
> fossil: Autosync failed
> ===
>
> If I'm local and I use file:// instead, it work no problem.. Should ssh://
> act like file:// since if we have write access to the ".fossil" file ?
>
> --
> Martin G.
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] push not allowed using ssh://

[Stephan Beal]

On Thu, Mar 29, 2012 at 5:55 PM, Martin Gagnon  wrote:

> Error: not authorized to write
> Received: 433  1  0  0
> Total network traffic: 778 bytes sent, 491 bytes received
> fossil: Autosync failed
> ===
>

IIRC Richard committed a fix for this recently:

http://fossil-scm.org/index.html/info/a928c89cb1

What fossil version are you using?

-- 
- 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] push not allowed using ssh://

[Martin Gagnon]

Hi list,

I notice that when using ssh:// protocole to clone, even if I have
read/write access to the fossil file from my ssh account, I cannot push to
it.

exemple: (with autosync ON)
===
$ fossil ssh://myhost/somepath/myrep.fossil myrep.fossil

$ mkdir rep
$ cd rep
$ fossil open ../myrep.fossil

  

$ fossil commit -m "some messages"
Autosync:  ssh://myhost/somepath/myrep.fossil
ssh -e none -T myhost
Bytes  Cards  Artifacts Deltas
Sent: 130  1  0  0
Received: 400  9  0  0
Total network traffic: 298 bytes sent, 459 bytes received
Closing SSH tunnel: New_Version: 45c982c33dfaeb2f96095604a3286a19237e9d48
Autosync:  ssh://myhost/somepath/myrep.fossil
ssh -e none -T myhost
Bytes  Cards  Artifacts Deltas
Sent:1194 14  0  2
Error: not authorized to write
Received: 433  1  0  0
Total network traffic: 778 bytes sent, 491 bytes received
fossil: Autosync failed
===

If I'm local and I use file:// instead, it work no problem.. Should ssh://
act like file:// since if we have write access to the ".fossil" file ?

-- 
Martin G.
___
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] http_proxy

[Lluís Batlle i Rossell]

On Thu, Mar 29, 2012 at 04:04:36PM +0200, Petr Man wrote:
> 2012/3/29 Lluís Batlle i Rossell :
> > Anyone using fossil with http_proxy set?
> >
> > Having http_proxy=localhost:8000
> >
> > I get, on any net operation:
> > fossil: unknown repository: localhost:8000
> 
> try http_proxy="http://localhost:8000";

Ah, that works. Thank you.

Is it really wrong, what I had? http_proxy=localhost:8000

It would have been nicer if fossil had told me a clearer message, but I
don't know how difficult is that to do. :)
___
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] http_proxy

[Petr Man]

2012/3/29 Lluís Batlle i Rossell :
> Anyone using fossil with http_proxy set?
>
> Having http_proxy=localhost:8000
>
> I get, on any net operation:
> fossil: unknown repository: localhost:8000

try http_proxy="http://localhost:8000";
___
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] http_proxy

[Petr Man]

2012/3/29 Lluís Batlle i Rossell :
> Anyone using fossil with http_proxy set?
>
> Having http_proxy=localhost:8000
>
> I get, on any net operation:
> fossil: unknown repository: localhost:8000

try http_proxy="http://localhost:8000";
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] http_proxy

[Lluís Batlle i Rossell]

Anyone using fossil with http_proxy set?

Having http_proxy=localhost:8000

I get, on any net operation:
fossil: unknown repository: localhost:8000

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] versionable ignore-glob problem

[Gour]

Hello!

I've problem with (versionable) ignore-glob...wanted to ignore bunch of
files belonging to my CMS which are in the root of my app, iow.

files/cache/*

but using the above pattern in my ~/.fossil-settings/ignore-glob does
not help and I had to put:

ignore-glob  (global) files/cache/*

via fossil's 'settings' command.

Any idea why the versionable ignore-glob does not work?


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though 
faultily, than another's duties perfectly. Destruction in the course 
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Handling a large number of repositories

[Dmitry Chestnykh]

Hello Christopher,

On 03/29/2012 12:56 PM, Christopher Berardi wrote:

Let's say I have a business that creates custom software or web sites
or mobile/web apps. For each project I maintain a repo for that project.
In such a case, what is the best strategy to handle what will likely (if
the business is successful) become a very large number of repositories?
Or is there another strategy to handle a scenario like this?


I currently have 58 Fossil repositories for my personal projects. 
There's nothing particular difficult in handling them. I have a small 
VPS with 256 MB of RAM on Rackspace Cloud (~$11/month), where they are 
stored, all in one folder. Fossil runs as CGI (set to "directory mode") 
under the chrooted Lighttpd server.


When I need to create a new repo, I just SSH into my server, create a 
repository there, then clone it into my notebook and begin working on 
the project. (This process can be improved by writng a script, but I 
haven't wrote it yet).


As I'm currently the only developer of most of my projects, I don't have 
to deal with user management. I setup a login group for repos, so that I 
need to log in only once. (I have one project where I needed to add 
another user -- it's not in this login group.)


The server has SSL turned on, with a free certificate from StartSSL.

For backups (on the server), I set up a daily cronjob, which dumps each 
*.fossil database using SQLite dump function into a temporary directory, 
then runs duplicity on this directory, which uploads copies of 
repositories to Amazon S3. Backups are encrypted with GPG.


I keep two folders on my notebook for Fossil repos, ~/fossils/pub for 
open source projects, and ~/fossils/priv for private ones.


When I once needed to clone all repositories into a new computer, I 
wrote a tiny script, which gets a list of project names and appends the 
correct URL and runs `fossil clone` on each of them.


--
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] Handling a large number of repositories

[Christopher Berardi]

Let's say I have a business that creates custom software or web sites
or mobile/web apps. For each project I maintain a repo for that project.
In such a case, what is the best strategy to handle what will likely (if
the business is successful) become a very large number of repositories?
Or is there another strategy to handle a scenario like this?

-- 
Christopher Berardi
http://www.natoufa.com/

May grace and peace by yours in abundance.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users