Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
Okay, after all that, I feel like distilling this down to its essence (according to my own opinions, naturally) might be in order. I feel like we basically have three sane options available: 1. Make some very minor changes to the Fossil source, where it generates pretty viewable web pages, to make it much easier to retrofit syntax highlighting via JS libraries for those users who want it. Get someone to write up a currently-effective guide to getting it set up, but make it a sort of unofficial, community guide. Do not officially support syntax highlighting at all. Do not bother screwing around with anything making line numbering play well with JS syntax highlighting unless and until someone presents a patch that fits with this philosophy of not supporting syntax highlighting but enabling it when easy to do so. 2. Pick a single JS syntax highlighting library (highlight.js) to bless. Include a guide in official docs for setting it up in deployment. Specify a supported version range for each Fossil release. Unless line numbering is found to be easy to work in, just write it off and officially declare that line numbering and syntax highlighting do not play well together, but keep that on the radar for figuring out later if possible. Call this "officially tested, but not officially supported". 3. Ship that library with Fossil. There's no need for identifying a supported range: either you use what ships with it or you're on your own, and we don't care any longer. I think taking this approach without resolving the line numbering problem has some issues for purposes of perception of the project, though, so I think one of the following two things should happen here: either call it experimental with firm plans to resolve the line numbering issue before calling it a release feature, or don't do this at all. While using an approach similar to GitHub's for purposes of easing transition from GitHub to self-hosted Fossil would be nice, if it's too much work to do so it shouldn't stand in the way of getting a good solution for Fossil. This feels like one of those "perfect is the enemy of good enough" situations, for a case that is only "perfect" with regard to ensuring people are slightly more inclined to switch from GitHub to self-hosted Fossil. In fact, considering there's probably nobody else providing that kind of fine-grained display characteristics similarity with GitHub, this doesn't feel like a critical issue at all. Most people probably just wouldn't even expect it to be that similar, I'd think. Follow RFCs carefully, provide similarity of implementation to GitHub for convenience if it's not too much trouble, and move on. YMMV. -- 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
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 11:40:01AM -0700, Sam Putman wrote: > > As a target, I would suggest the emitted html look as much like this > as possible: > > view-source:https://github.com/jvirkki/libbloom/blob/master/bloom.c > > The actual code block begins at line 821. > > This style of markup is a de-facto standard and leads to a linking > style that would greatly aid migration from git if fossil could adhere > to it. My example was nothing but off the top of my head equivalent to pseudocode (except I think the code was all valid HTML around valid C). Only the class names change between my version and this version, apart from some extra details like data-line-number and id properties, in any case. That means I was evidently thinking identically (in principle) to the thoughts of whoever wrote the code that produced your example. I'm not sure how this has any effect on migration from git to fossil, though. Git export and Fossil import wouldn't touch this code. Are you talking about some kind of external tools being able to interact with this code in the browser? If so, the classes involved probably come from whatever JS library is used for syntax highlighting anyway, rather than from something like code internal to Fossil (unless syntax highlighting gets implemented in C as part of Fossil). I guess the upshot is that I'm not sure what you mean, and all I've been able to do so far is guess. -- 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
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 12:11:11PM -0500, Lester L. Martin II wrote:
> On 2018-06-28 11:07, Chad Perrin wrote:
> >
> > I think a cleaner approach, though it might take a bit of rewriting for
> > file display, would use an HTML table, possibly assembled by
> > JavaScript.
> > Note that I'm feeling a little dirty for suggesting this; it's
> > something
> > that could also reasonably be done server-side, though it would
> > probably
> > require using something server-side for the syntax highlighting, too.
>
> Server side syntax highlighting is an excellent idea, though I'm not
> quite sure at this time how to implement it. The other issue with such
> being that fossil would basically need to cache the results of running
> a highlight for the liftime of the program up until something
> invalidates the cache. Line numbering does/will need serious work to
> integrate with syntax highlighting regardless of the approach.
Yeah, that'd probably be more work overall, and would likely reduce the
customization for syntax highlighting allowed to people deploying Fossil
repositories to the web. It would make how line numbering and syntax
highlighting integrate much more "deterministic", though, in that Fossil
devs would have a clearer view of everything that happens when trying to
account for it in updates to Fossil source. It's a trade-off, as with
most such decisions.
> >
> > See if this makes sense:
> >
> > Apply syntax highlighting to a block of code. Organize the code in
> > second column TD elements of a table. Organize line numbers in
> > first column TD elements of a table.
> >
> > Thus, you would have HTML for a line of code that looks something
> > like this (using a totally made-up function as example code):
> >
> >
> > $num
> >
> > uint16_t > class="color-label">get_next() {
> >
> >
>
> Basically how GitHub and several other things implement it.
I guess my intuition about how to handle it is in good company, for some
definition of "good".
> >
> > Of course, that's just off the top of my head. I don't actually
> > know how the HTML resulting from application of the syntax
> > highlighting code would look in this case. The upshot, though, is
> > that applying syntax highlighting to the code to be displayed first,
> > then organizing it into table cells with number cells, might avoid
> > JS syntax highlighting issues with line numbers, including any
> > issues around multiline highlighting. The downside is that it would
> > result in either having to do all line numbering in JS or applying
> > syntax highlighting server-side.
>
> The issue with just applying highlights first is how will line endings
> be tracked since html elements need not necessarily be rendered
> similarly by all highlighting libraries. Detecting line endings in a
> generic way after markup has been applied will be very difficult and
> likely library specific. I keep using Prism.js as my goto for
> illustration but I would bet that the differences between hljs and
> prism are enough that the JS needing to be written to (hopefully)
> detect marked up line endings between them would be different and we
> get into a "supports $library" case vs a generic case like it has been
> so far without syntax highlights and how it'd remain if we didn't go
> forward with syntax highlighting when lines are numbered.
If you mean that syntax highlighting libraries might insert literal
newlines into the file when marking it up for highlighting, that's
pretty awful, and could indeed screw up the whole exercise.
>
> We still would end up depending on the "Line numbers" checkbox being a
> call into JS to add those in for everything but the server-side case.
> I'd rather not have to write JS to try to target 2 different
> highlighting engines (or possibly more dependent upon what other users
> prefer). Then that means that we'd need to check the JS code written
> against say... the latest 3 versions of each highlighting engine in
> our "support list". At that point it could be said that our hold ups
> in deploying a new version are tied up in making sure integration with
> several external resources will move along properly. We'd also get
> into a case of saying "supports up to $version_number of this library"
> (and more of those statements for other libraries supported). At this
> point I came to the conclusion it's a huge undertaking and would
> require extensive long term management, and believe at that point, it
> might be best to &q
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Thu, Jun 28, 2018 at 10:40:19AM -0500, Lester L. Martin II wrote:
>
> I've developed a way to do highlighting with line numbering...
> The issues are as follows however:
> 1. The JS code responsible for the highlighting is external to Fossil
> itself.
> 2. The JS code highlights blocks, so if there is a
>`$line$line2` each code block is
>highlighted individually.
> 3. Context is lost between code blocks.
>
> Each line gets wrapped in a separate code block because you can use
> css to insert a line number vs manually inserting the line number via
> code per line.
>
> That said, if you have a comment block `/* comments */` broken up over
> a few lines, it won't apply the comment coloring to the lines
> in-between when line numbering is enabled. Thus, I'd consider that
> while it half works, such is inherently broken unless we decide to
> depend upon a certain JS library to handle highlighting.
I think a cleaner approach, though it might take a bit of rewriting for
file display, would use an HTML table, possibly assembled by JavaScript.
Note that I'm feeling a little dirty for suggesting this; it's something
that could also reasonably be done server-side, though it would probably
require using something server-side for the syntax highlighting, too.
See if this makes sense:
Apply syntax highlighting to a block of code. Organize the code in
second column TD elements of a table. Organize line numbers in first
column TD elements of a table.
Thus, you would have HTML for a line of code that looks something like
this (using a totally made-up function as example code):
$num
uint16_t get_next() {
Of course, that's just off the top of my head. I don't actually know
how the HTML resulting from application of the syntax highlighting code
would look in this case. The upshot, though, is that applying syntax
highlighting to the code to be displayed first, then organizing it into
table cells with number cells, might avoid JS syntax highlighting issues
with line numbers, including any issues around multiline highlighting.
The downside is that it would result in either having to do all line
numbering in JS or applying syntax highlighting server-side.
--
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
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On Wed, Jun 27, 2018 at 11:31:57PM -0500, Lester L. Martin II wrote:
> This patch changes the way `void artifact_page(void)` renders a files
> content. Formerly a `` was issued for content,
> whereas now a `` is issued where
> $ext is the file's extension (example, "blah.lua" extension would be
> "lua").
>
> This allows for proper integration with syntax highlighting systems
> such as "highlight.js" and "prism.js" where only the former was
> tested. This allows syntax highlighting without having to have
> language detection.
It's pretty cool you did this. I'm going to look over this and the
syntax highlighting tools that might work with it to see if I want to
start using it, though I guess I'd have to compile my own Fossil if I
wanted to do it sooner rather than later. Thanks for the work.
>
> Remaining work likely includes changing the CSS of all themes to take
> this into account. Other things that might be considered is to
> conditionally remove the `` part from all but the content
> rendering. Another part would be rendering syntax highlights with line
> numbers (currently unimplemented).
Have you checked it against any themese to see if it affects them at
all? If so, which themes did you find weren't problematic? I'm
guessing that if you found some that were you'd mention it.
>
> Below is the output of 'fossil diff' ran against checkout
> '6a7d2ad8f1dd5c542eba0b885418328803d8d802' with my changes:
>
> Index: src/info.c
> ==
> --- /home/masky/misc/fossil/src/info.c~0 2018-06-27 23:21:48.520779000
> -0500
> +++ /home/masky/misc/fossil/src/info.c2018-06-27 16:48:28.683256000
> -0500
> @@ -670 +670 @@
> -
> +
> @@ -2157 +2157,2 @@
> -const char *z;
> +const char *z, *ext, *name;
> +char *tmp;
> @@ -2158,0 +2160,3 @@
> +name = blob_str(&downloadName);
> +
> +ext = (tmp = strrchr(name, '.')) == NULL ? "" : tmp+1;
> @@ -2162 +2166 @@
> - @
> + @
> @@ -2164 +2168 @@
> - @
> + @
> @@ -2232 +2236 @@
> - ? db_text("(No title)",
> + ? db_text("(No title)",
>
> !!END!!
>
> I'm unsure why "@@ -2232 +2236 @@" section got included as no changes
> were
> made to that.
I haven't looked at the code in context; I've only seen the patch you
inlined in the email so far. It looks sane to me, though. I might come
back and look at it again in the morning, and check it against the
Fossil source code for context.
>
> I would like to submit a contributor agreement to make it official. This
> change is so small that my previous post to the list serv considered,
> one could have implemented it in less time than it would take for a
> contributor agreement to finally be filed but as there was no reply
> I didn't wait upon such.
Even if they want the contributor agreement on file before incorporating
it, I'm glad you sent it to the list for people who might want to start
using it sooner than the next Fossil release.
--
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
Re: [fossil-users] Markdown in tickets
On Tue, Jun 26, 2018 at 12:05:51PM -0400, Richard Hipp wrote: > On 6/26/18, Andy Goth wrote: > > Is there a reason why Fossil tickets don't allow markdown? The format > > options are wiki, HTML, plain text, and [links only]. > > Markdown as a formatting option can be added by configuration. > > Perhaps you are asking for Markdown support to be added to the default > configuration? I am running Fossil v2.5 here: $ fossil version This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC I see no Markdown formatting option for tickets when visiting the web UI via `fossil serve`: https://i.imgur.com/F3UL8kc.png It only shows Wiki, HTML, Plain Text, and [links only]. -- 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
Re: [fossil-users] Perception of Fossil
On Sat, Jun 16, 2018 at 05:05:48PM +0200, Eduardo Morras wrote: > > I partially disagree. If you allow anonymous people to pull / commit / > merge data to your 'central repository', you can get easily spammed. > If I pull-request 100 images of 10MB your system will go down. > Multiply it by several 'funny guys' on more than one repository and > fossil credibility / reputation will be -1. > > People that could pull anything to any repository must be trust > people. (Don't know if it's correct phrase) I think that's a matter for configuration, just like whether to allow people to self-register through the web UI and what initial permissions a registered user should have. It is not, in my estimation, a matter of whether or not this is a desirable feature *at all*. This could, in fact, be a very important feature for some team workflows where there may be some devs who are allowed to do this, and others who are allowed to commit/push directly (and given the ability to handle a contributed branch like this, to merge or otherwise accept). -- 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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 04:39:20PM -0400, Richard Hipp wrote: > On 6/15/18, Chad Perrin wrote: > > > > This would not technically be a "pull request". It would be a "merge > > request". > > Good point. It should not be called "pull-request" as pulling does > not come into play. > > On the other hand, it is not necessary a request to merge. Often a > merge is implied, but the reviewer instead might prefer to accept the > changes but leave them on a branch. In that case it might be called > "push-request". Once the branch gets pushed, then merging can come > later. You make a good point about the intention not necessarily being a merge per se. Of all the suggestions I've seen so far, I think the best so far are: * contribute - describes the sender's intention very generally * push-request - matches format of "pull request" * submit - describes the sender's action very specifically The downside of push-request, of course, is that it imperfectly describes what is going on. The push has already been accomplished at that point, though it was pushed to a sort of "pending" status. I submit that all three of these, for various reasons, have sufficient merit for this purpose, and I propose that bikeshedding the name be tabled in favor of one of these as a "working title" for the feature, with the proviso that it may be changed at some point before there is a working/testable, presumably-final-form feature in development. YMMV, as always. -- 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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 01:35:13PM -0400, Richard Hipp wrote: > > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get anon-patch working. > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > branch and then transmits that bundle back to the server from which > the clone originated. > > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived. > > (6) Developers who receive notification of the pull request can run a > command that pulls down the bundle and applies it as a private branch > on their own personal clones of the repo. Developers can then either > approve of the pull request by publishing it (marking it non-private) > and pushing it back to the server. Or they can reject the pull > request which erases it from their clone. They might also cause the > pull request to be erased from the holding table on the server. > > Additional notes: > > Prior to step (3), Fossil might require Anonymous to provide contact > information so that developers can get in touch in case there are > questions or requests for clarification. Anonymous might also be > asked to sign a contributors agreement to be included in the bundle > (as an entry in the bconfig table). Just one correction: This would not technically be a "pull request". It would be a "merge request". The branch would already be pushed to the upstream repo, but not yet merged. In a technical pull request, a request is sent to the upstream repo to pull from the downstream repo, which I believe you can already do with Fossil (albeit not automagically like GitHub allows). I would call that feature either "merge request", as I already called it, or "push request" if there is some perceived need for "pull request" similarity for buzzword compliance purposes. I think it is important to ensure our commands and features have names that reflect what they actually do as much as that is reasonably possible to ensure. -- 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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 12:55:34AM +0100, Thomas wrote:
> On 2018-06-15 00:32, Chad Perrin wrote:
> >> Pull requests are not supported, hence the software can't be used for
> >> community driven open source.
> >
> > The pull request interface on GitHub is a feature of GitHub, not of Git.
> > While it would be nice to have a similar feature built into the Fossil
> > web UI, doing it the same way would require having a centralized website
> > on which to implement it. Something similar could theoretically be
> > supported in Fossil itself, but would not be identical to the way
> > GitHub's pull request feature works.
>
> Yes, sorry for the ambiguity. When people talk about git they
> automatically mean github.
s/people/some people/
You don't need GitHub for open source development.
--
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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 09:27:31PM +0200, Nicola Vitacolonna wrote: > On 15/06/2018 01:32, Chad Perrin wrote: > > On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: > >> > >> Pull requests are not supported, hence the software can't be used for > >> community driven open source. > > > > The pull request interface on GitHub is a feature of GitHub, not of Git. > > While it would be nice to have a similar feature built into the Fossil > > web UI, doing it the same way would require having a centralized website > > on which to implement it. Something similar could theoretically be > > supported in Fossil itself, but would not be identical to the way > > GitHub's pull request feature works. > > FWIW, GitHub pull requests have been harshly criticised by Linus > Torvalds himself [1]. Git does have its own method (`git am`). Maybe, > Fossil could implement something along the lines of `git am`. > > [1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 I don't know that I'd describe the GitHub pull request concept in such strictly negative terms as Linus does, but it does have shortcomings for some purposes. It might also be nice to have a merge-by-email feature in Fossil similar to Git's (which is more of a "merge request" than a "pull request"). On the other hand, it's already pretty easy to "hand-craft" a pull request for Fossil, if I'm not mistaken, as long as you have a repository that's actually accessible to the recipient of the request. Just send an email or other message with the pull URI for your changes, and let the recipient use the `fossil pull` command. Is there something important I'm missing for this approach? -- 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
Re: [fossil-users] Perception of Fossil (dumb idea for pull requests)
On Thu, Jun 14, 2018 at 08:17:47PM -0600, Warren Young wrote: > > Back when I proposed the feature set that became bundles, I proposed > that it include a way for the outside contributor to create a ticket > from a bundle, which would be pushed to the remote repository for > disposition by someone with a commit bit. > > That never happened, but now I think it’s another good reason for > Fossil to have a forum feature. Someone with a forum login on a > repository but lacking a commit bit could say > > $ fossil bundle push --branch my-new-feature > > and have their un-sync’d my-new-feature branch bundled and pushed > to a sub-forum dedicated to accepting unsolicited outside > contributions. > > Effectively, the new “push” verb is “fossil bundle export > && send to contribution sub-forum,” with the local Fossil instance > transferring it directly to the remote just as with the normal push > feature. > > Someone with a commit bit could then do a one-click integration of the > bundle branch from the forum UI, presumably after testing it locally > on their machine. > > There are several advantages to doing it through Fossil UI instead of > the current mechanism: > > 1. fossil bundle import && test && fossil bundle import --publish && > send email is more involved than fossil up my-new-feature && test && > click “Integrate” in Fossil UI. > > 2. Like closing a ticket combined merging a branch with --integrate, > clicking that button would auto-close both the forum thread and the > branch. > > 3. By integrating it so tightly, the committer doesn’t need to > explicitly involve the local filesystem at all. The local Fossil > instance gets a copy of the bundled branch with the next sync past the > outside contributor’s push, and the integrate happens using that > same contributed bundle. There’s no need to rm > ~/Downloads/my-new-feature.bundle after integrating the bundle, nor > the bulky email containing it. > > 4. Now we’d have pull requests to shut the Git fans up, except > that they’d actually be push requests. :) I'm not a fan of functionality that isn't specifically about a GUI being implemented only in the GUI. Give me a command-line way to handle it as well, at least. In fact, I would be happier with CLI-only than with GUI-only (which in this case would be web-only). -- 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
Re: [fossil-users] Back on-line. Was: Mailing list shutting down...
On Fri, Jun 15, 2018 at 11:32:41AM +, Pietro Cerutti wrote: > > Oh so it looks they don't offer proper mailing lists (the ones people > can subscribe and reply to) but only newsletters, which they call > mailing lists, so sorry for the noise and my confusion. I also worked on a project for a MailChip client at one point and the business practices around MailChimp turned out to be somewhat suspect in terms of providing consistent service. It handled mass email management fine, but it did some rather weird stuff with how it changed its services and notification of changes and so on that left me with a bad taste in my mouth. -- 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
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: > > Pull requests are not supported, hence the software can't be used for > community driven open source. The pull request interface on GitHub is a feature of GitHub, not of Git. While it would be nice to have a similar feature built into the Fossil web UI, doing it the same way would require having a centralized website on which to implement it. Something similar could theoretically be supported in Fossil itself, but would not be identical to the way GitHub's pull request feature works. -- 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
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 11:04:18PM +0100, Thomas wrote: > > I forgot to mention that self-registration is something that comes along > the same line. I haven't managed to get this working with Fossil yet either. > > As far as I can see until now you got to create an account for every > contributor yourself. There's a checkbox setting on the admin "Access" page that reads as follows: [ ] Allow users to register themselves Allow users to register themselves through the HTTP UI. The registration form always requires filling in a CAPTCHA (auto-captcha setting is ignored). Still, bear in mind that anyone can register under any user name. This option is useful for public projects where you do not want everyone in any ticket discussion to be named "Anonymous". -- 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
Re: [fossil-users] Back on-line. Was: Mailing list shutting down...
On Thu, Jun 14, 2018 at 09:05:14AM -0400, Richard Hipp wrote: > On 6/13/18, Richard Hipp wrote: > > Unfortunately, I'm going to need to shut down this mailing list due to > > robot harassment. I am working to come up with a fix or an > > alternative now > > Mailing lists are now back on-line and once again accepting > subscriptions. I have implemented measures to block the subscription > robots and to better log subscription activity to better detect future > mischief. > > I consider this to be a stop-gap measure that will buy me some time to > implement and test a better log-term solution. The current setup will > change. But the temporary measure I implemented this morning do at > least get us back to a functional mailing list while work on the > improved solution proceeds. It looks like the mailing list page itself is still down for this list. http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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
Re: [fossil-users] Jenkins plugin for Fossil
On Wed, May 21, 2014 at 06:08:25PM -0400, Ronald Perrella wrote: > Hi Folks, > > I apologize if this appears to be a repost. I'm not a frequent mailing list > user. > > I've uploaded a Jenkins Plugin for Fossil to my GitHub repository for those > who might have an interest. It is Java source-only at this point and it's > been a while since I've synced with the latest Jenkins source. However, it > worked for my purposes and I know there are others who might want to try > it. If you're handy with Java, you should be able to easily recompile it > with Maven. Feel free to fork it or provide feedback on my account. > Naturally, it comes without warranty of any kind. > > You can find the code at *https://github.com/rjperrella/jenkins-fossil-adapter > <https://github.com/rjperrella/jenkins-fossil-adapter>* I see there haven't been any commits to this repository since 2014. Is this still actively used, reliable, and (as needed) actively maintained, or is it effectively abandonware? It's an interesting project that I somehow missed seeing in the mailing list until just now. -- 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
Re: [fossil-users] anyone using email addresses as user names?
On Wed, Mar 19, 2014 at 04:34:35PM +0100, Stephan Beal wrote: > On Wed, Mar 19, 2014 at 4:33 PM, Richard Hipp wrote: > > > I have private repositories with hundreds of email-address user names. > > Never had an issue. > > > > Thanks! That's about as an authoritative answer as could be hoped for :). Having stumbled across this message again after a couple years, I realize I should probably account for this behavior in my fossgit tool. I'm not sure exactly how to account for it yet, but it's now on my mind. Do you have any suggestions for how to handle situations like this in a tool that eases the process of mirroring Fossil repositories as Git repositories? People might prefer sticking email addresses in a user's email setting and do something else with the username. Actually . . . now that I think about it (yes, this email is almost stream-of-consciousness), I wonder if it might make more sense to just include some options for specifying usernames and email addresses, as an alternative to just automagically using the Fossil username as the GitHub username and the Fossil email address as the GitHub email address in exported commits. What do you think? -- 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
Re: [fossil-users] Introducing FossGit -- a new CLI tool for conveniently mirroring Fossil to Git.
On Wed, Dec 28, 2016 at 08:57:20AM -0700, Warren Young wrote: > On Dec 25, 2016, at 11:13 AM, Chad Perrin wrote: > > > > new utility called FossGit for > > creating and maintaining Git mirrors of Fossil repositories: > > Does it cope with the fact that Fossil allows a given tag to appear > multiple times in a repository but Git does not? > > In order to atttain git fast-export compatibility in a repository > recently, I had to manually go in and cancel all the superseded tags. > It would be nice if either Fossil proper or a tool like yours would > just export that tag on the most recent checkin, so that Git and > Fossil agree on the meaning of the tag. It does not (yet) do that. If you want to discuss with me how that might be reasonably accomplished in an automatable manner, I'll try to make that a priority for the next FossGit release. -- 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] Introducing FossGit -- a new CLI tool for conveniently mirroring Fossil to Git.
Introducing FossGit: "Good news, everyone! I just published a new gem!" - Dr. Farnsworth As announced here, I published a simple new utility called FossGit for creating and maintaining Git mirrors of Fossil repositories: https://twitter.com/apotheon/status/813072784238804993 The rubygems page is: https://rubygems.org/gems/fossgit The Fossil repository is: https://fossrec.com/u/apotheon/fossgit/index.cgi/index The Git mirror (created/maintained by FossGit itself) is: https://github.com/apotheon/fossgit/ It's basically a glorified shell script at this time. It will probably become much more at some point. Happy holidays. -- 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
Re: [fossil-users] incorrect user info in export --git
On Sun, Dec 25, 2016 at 12:22:43PM -0500, Ron W wrote: > > I only use git when I have to, generally when a project requires submitting > pull requests. In that case, I still track my local changes in Fossil. Then > I pull the latest into my clone of the git repo, merge the changes into my > work space, rebuild, retest abd repeat as needed. Then I commit the "final" > changes to my clone and send the pull request. That sounds like a use case for what I've built, plus functionality going the other way (Git->Fossil), which I haven't built (yet). Of course, all this stuff is handled by export and import commands for both Fossil and Git, but I built something to mirror Fossil repositories to Git repositories so I could simplify my life somewhat when doing that. > > At work, the controls software group uses Fossil "internally", but the > company is still "standardized" on SVN (because the IT group's vision is > for "thin client" PCs that are fully interchangeable, which doesn't work > for my group because we need specialized tool chains that don't "play well" > with IT's vision). We use Fossil for our day-to-day work, only committing > releases to SVN. It seems like you have need of tools for import/export mirroring with Subversion, too. -- 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
Re: [fossil-users] incorrect user info in export --git
On Sat, Dec 24, 2016 at 12:47:43PM -0800, bch wrote: > On Dec 24, 2016 10:05, "Stephan Beal" wrote: > > On Sat, Dec 24, 2016 at 6:42 PM, Chad Perrin wrote: > > > I hope the lack of responses to my questions was because of the holiday > > season > > > Or maybe interest in git is slowly dying off ;). > > > Ever hopeful... I wish, but from what I've seen that's not happening in the wider world. I'd easily believe people who start using Fossil end up losing interest in Git, though. -- 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
Re: [fossil-users] incorrect user info in export --git
On Sat, Dec 24, 2016 at 09:29:01AM +, Chad Perrin wrote: > On Tue, Dec 20, 2016 at 11:35:46PM +0000, Chad Perrin wrote: > > When exporting from a Fossil repository and importing into a Git > > repository, the commits all seem to identify the email address as the > > name and the name as the email address. The command I use is > > essentially identical to what the documentation/example at > > fossil-scm.org, and I do not see a way in the help documentation for the > > tool or on the website for how to control the way it identifies the > > author of a commit on export. > > > > Is there a work-around for this? Is this a problem affecting anyone > > else? Any help figuring this out would be appreciated. > > Is there any reason piping the Fossil export through sed to fix name and > email, then piping the correct result into Git, would not work? I only > ask because it does not seem to work here. I used a sed regex that I > have verified works on a string copied from an unmodified Fossil export, > but for some reason does not work when I actually try to use it by > sticking it between the Fossil export command and the Git import > commands, connected together via pipes. I've confirmed the sed approach works. Borrowing directly from here: https://www.fossil-scm.org/index.html/doc/trunk/www/inout.wiki . . . but simplifed, somewhat, with a sed command in the middle, the end result looks like this: fossil export --git --export-marks ../repo/fossil.marks \ ../repo.fossil | sed \ 's/^\(committer \+\)\([^ ]\+@[^ ]\+\)\( *<\)\(\w\+\)\(>.*\)$/\1\4\3\2\5/' \ | git fast-import --export-marks=../repo/git.marks The regex is a little long. I might try to pare it down slightly, at some point. I'll also try to find time to report an issue with Git export formatting that swaps email and name info, then if I feel *very* ambitious about the time I have available to spend I might also try submitting a patch to close the issue. Don't hold your breath, though; life is crazy, and my to-do list is already long. I hope the lack of responses to my questions was because of the holiday season, because that means you all might be having a good time. -- 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
Re: [fossil-users] incorrect user info in export --git
On Tue, Dec 20, 2016 at 11:35:46PM +, Chad Perrin wrote: > When exporting from a Fossil repository and importing into a Git > repository, the commits all seem to identify the email address as the > name and the name as the email address. The command I use is > essentially identical to what the documentation/example at > fossil-scm.org, and I do not see a way in the help documentation for the > tool or on the website for how to control the way it identifies the > author of a commit on export. > > Is there a work-around for this? Is this a problem affecting anyone > else? Any help figuring this out would be appreciated. Is there any reason piping the Fossil export through sed to fix name and email, then piping the correct result into Git, would not work? I only ask because it does not seem to work here. I used a sed regex that I have verified works on a string copied from an unmodified Fossil export, but for some reason does not work when I actually try to use it by sticking it between the Fossil export command and the Git import commands, connected together via pipes. -- 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] incorrect user info in export --git
When exporting from a Fossil repository and importing into a Git repository, the commits all seem to identify the email address as the name and the name as the email address. The command I use is essentially identical to what the documentation/example at fossil-scm.org, and I do not see a way in the help documentation for the tool or on the website for how to control the way it identifies the author of a commit on export. Is there a work-around for this? Is this a problem affecting anyone else? Any help figuring this out would be appreciated. -- 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] sync commits with GitHub
Does anyone have a good solution for updating a GitHub repository with commits from a Fossil repository? I don't need the GitHub repo to accept any commits from anywhere else at this time. -- 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
Re: [fossil-users] committing wiki pages changes format parser
On Tue, May 13, 2014 at 09:55:10AM +0200, Stephan Beal wrote: > On Tue, May 13, 2014 at 12:12 AM, Chad Perrin wrote: > > > > When I use the "fossil wiki" command to work with wiki pages at the > > shell, edit files and check them back in, what was once treated as a > > markdown formatted wiki page gets coerced back to being a "wiki markup" > > formatted wiki page. How do I stop this from happening? > > Doh - you can't currently. The shell mode export/import was added _long_ > before other formats were supported, and it's not aware of them. i've added > that to the TODO list. Thanks. I look forward to that going away. > > > > While I'm at it . . . how do I stop changes saved from the web interface > > from inserting a bunch of MS Windows style "^M" CRLF character garbage > > at the end of every line when I check out a wiki file locally for > > editing in a text editor? > > > > That's new to me - i don't recall ever having seen that. Is there any other information I could provide that might help narrow down the source of the problem? I'm currently at kind of a loss. The local install of Fossil is 1.28 built from ports on FreeBSD. The remote install is 1.26 built from downloaded sources on a Linux-based webhosting platform (though I expect to move that to a FreeBSD VPS, with Fossil installed from ports and thus more up to date, "soon"). -- 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] committing wiki pages changes format parser
When I use the "fossil wiki" command to work with wiki pages at the shell, edit files and check them back in, what was once treated as a markdown formatted wiki page gets coerced back to being a "wiki markup" formatted wiki page. How do I stop this from happening? While I'm at it . . . how do I stop changes saved from the web interface from inserting a bunch of MS Windows style "^M" CRLF character garbage at the end of every line when I check out a wiki file locally for editing in a text editor? -- 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
Re: [fossil-users] Merging two leaves not on the same graph?
On Thu, May 01, 2014 at 02:42:58PM -0500, Andy Goth wrote: > > That explains it. You created a new repository and pushed to it, but > that new repository had that unwanted empty commit, set to the current > date and time. > > Whenever I convert an existing project to Fossil, I have to do [fossil > new -date-override] to specify the date of the initial commit, putting > it before the oldest commit I'm going to be putting into it. Wow. Where was this information/advice when I was asking about importing from Git to an existing "empty"/new Fossil repository a while back? Thank you! I'm going back to trying to use Fossil for those projects, instead of sticking with Git, now. -- 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
Re: [fossil-users] New Fossil GUI Completed v1
On Sat, Apr 26, 2014 at 12:23:49PM -0700, Paulus Tuerah wrote: > > Thanks for the great and the simplicity of Fossil (1 exe file without > installation is really great). But unfortunately there is no GUI. > > Coming from SVN using Tortoise SVN, there is no way I will do version > control with CLI. So I decided to make GUI for Fossil. I do not see any license information for this stuff. Maybe you should add a LICENSE file to the project directory. I'd suggest using the same license as Fossil, for a number of reasons including simplicity of dealing with licensing as a recipient of the software. -- 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
Re: [fossil-users] a bit of healthy fossil/git rivalry...
On Fri, Apr 11, 2014 at 11:02:52AM +0200, Stephan Beal wrote: > Maybe fossil needs such a tool... > > http://git-man-page-generator.lokaltog.net/ > > Be sure to tap F5 a few times and re-read the page each time. I think my favorite so far might be git-rub-tree. -- 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
Re: [fossil-users] Tracking System Configuration Files - Best Practices
On Thu, Apr 24, 2014 at 12:23:29AM -0400, Ron Wilson wrote: > On Wed, Apr 23, 2014 at 9:38 AM, Will Parsons wrote: > > > This kind of stuff isn't a "project", and you don't > > need the extra stuff that Fossil (or Git, Mercurial, Bazaar, > > Subversion, or CVS) provide. I've tracked system files for over a > > decade with RCS (and before that with SCCS) and see no reason to > > change. > > > > I disagree. Very often system changes have to be coordinate across several > config files. Most distributions have admin tools to take care of this, but > don't track the history of the changes. For most uses, this is fine. > > Where I work, the IT people already use a tool like Tripwire to monitor the > status (including ownership and permissions) of system critical directories > and files. Another part of this tool is used to reset the permissions, > ownership, etc of these files when changes are made. Because of this, they > can - and do - use Fossil to track system configuration changes. > > By using this combination of distribution provided tools, a few custom > tools, the Tripwire like tool and Fossil, they actually have more and > better control of configuration. And they save the company several $10k per > year in licensing fees for commercial system management suites. What are the chances you could produce a description of how this setup is used such that it would provide a howto for setting up similar systems in other people's networks, or convince someone else to write such a thing? This could make for an excellent article somewhere. -- 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
Re: [fossil-users] wiki edits outside HTML UI
On Wed, Apr 23, 2014 at 07:22:20PM +0200, Stephan Beal wrote: > On Wed, Apr 23, 2014 at 7:10 PM, Martin Gagnon wrote: > > > And when you edit with your local editor, you can visualize your change > > before commit using "fossil ui" and pointing your browser to > > http://localhost:8080/doc/ckout/../path/to/file.md > > > Nice tip - i never thought of that (or had forgotten it) for previewing > wiki pages. > > @Chad: > > fossil export PageName foo.wiki Ah, now I see why it only works on Emacs for you. On FreeBSD+nvi this works: fossil wiki export PageName foo.wiki > > then visit your local server with the path /doc/ckout/foo.wiki > > that should do the trick. Actually, I think I'll probably just use a wiki directory within the project's base directory, check out files there, and commit them to the main repository, as a workaround for making it possible to edit the wiki as part of the main repository. There just needs to be a checkout from the wiki every time before editing, then a double-check to make sure someone hasn't changed the wiki again before importing the file contents back into the wiki. I'd really like to see the possibility of edit race conditions eliminated, of course, but I don't see a "good" way to do that without making it possible to either have a separate wiki checkout complete with merge and all the trimmings or integrate the wiki directly with the main check-out-able repository. Is there any chance of such a feature being added in the nearish future . . . ? -- 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
Re: [fossil-users] wiki edits outside HTML UI
On Wed, Apr 23, 2014 at 12:52:36PM -0400, Richard Hipp wrote: > On Wed, Apr 23, 2014 at 12:50 PM, Chad Perrin wrote: > > > > > Oh, never mind, the embedded docs won't do me any good, because I use > > FreeBSD, not GNU/Emacs. > > > > ??? What does your OS and editor choice have to do with anything? There's an old joke about Emacs, that "It's a nice operating system, but it lacks a decent editor." [1] He kept bringing up the (obviously tongue-in-cheek) idea that his solutions only work with Emacs, so I finally pointed out that I'm using a different "operating system" than him. Just a joke back for a joke he was making. Sorry about the confusion. NOTES: 1. I actually think that joke about Emacs is terribly unfair. It comes with a great editor, called Viper Mode. -- 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
Re: [fossil-users] wiki edits outside HTML UI
On Wed, Apr 23, 2014 at 06:36:38PM +0200, Stephan Beal wrote: > On Wed, Apr 23, 2014 at 6:29 PM, Chad Perrin wrote: > > > > . . . so basically I need to list wiki pages to figure out what I want, > > export a page, edit that, then commit it to overwrite what's already > > there, one file at a time, rather than having a checked out directory of > > wiki stuff I can just edit and commit as I would a normal set of > > repository files. Is that correct? > > Correct. > > > > > It seems cumbersome > > Correct. That's . . . encouraging. > > > > , but I'll see if it's so cumbersome that I'd rather > > just use the HTML interface, or whether it actually suits my needs. > > > > Sounds like a plan. Suggestions are welcomed. > > I haven't really looked at the "embedded docs" thing yet to see whether > > that's something I should be using, but I definitely need the wiki > > interface for at least some projects, and would like to be able to edit > > them in much the same way I can edit standard repository files, so the > > "embedded docs" feature doesn't seem to solve all my problems in this > > regard. > > > > Embedded docs are normal repository files, You can edit them with emacs > (doesn't work with anything else ;) and preview them with "fossil > server/ui" using the path /doc/ckout/path/to/the/file (i think that's the > right path, anyway). But you can't edit them from the HTML interface (nor > the JSON API), largely because they _are_ normal files and thus are managed > using the normal commit mechanism (which requires a checkout, which remote > CGI/server instances normally do not have access to). Okay, yeah, that'll be handy -- but not suitable for my need/desire to make the wiki editable from the console (obviously), as I definitely need to make wiki pages available for editing from the web interface as well. Does the embedded docs feature do markdown formatting? Wait. I'll go look at documentation so you don't have to start answering questions that are easily answered by doing some research. Oh, never mind, the embedded docs won't do me any good, because I use FreeBSD, not GNU/Emacs. -- 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
Re: [fossil-users] wiki edits outside HTML UI
On Wed, Apr 23, 2014 at 06:06:17PM +0200, Stephan Beal wrote: > On Wed, Apr 23, 2014 at 6:04 PM, Stephan Beal wrote: > > > > 'commit' to save the changes. Unfortunate there's not a direct way to > > preview changes without saving unless you want to use the JSON API (which > > provides "preview" feature for wiki text passed to it). > > If that feature would really help you, though, let me know - it would > likely take only 15 minutes to add "fossil wiki preview INFILE ?OUTFILE?", > which takes a file as input, processes as wiki, and writes the processed > form to a new file or stdout. If I understand correctly what you propose, I do not think I particularly need that at this time. I'm just looking for the ability to edit markdown for wiki pages locally without having to fire up the web interface (which might be especially important in cases where "locally" happens to be via SSH on a remote system without X). I should probably consider whether (less gifted at correct spelling) other contributors might need that, though. -- 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
Re: [fossil-users] wiki edits outside HTML UI
On Wed, Apr 23, 2014 at 06:04:18PM +0200, Stephan Beal wrote: > On Wed, Apr 23, 2014 at 6:00 PM, Chad Perrin wrote: > > > Is there some way to check out the wiki and make edits as one would for > > standard repository files, to be committed like standard repository > > files, rather than always having to use a browser to edit the wiki? I > > > > Kinda of: > > [stephan@host:~/cvs/fossil/libfossil]$ f help wiki > Usage: f wiki (export|create|commit|list) WikiName > > Run various subcommands to work with wiki entries. > > f wiki export PAGENAME ?FILE? > >Sends the latest version of the PAGENAME wiki >entry to the given file or standard output. > > f wiki commit PAGENAME ?FILE? > >Commit changes to a wiki page from FILE or from standard >input. > > f wiki create PAGENAME ?FILE? > >Create a new wiki page with initial content taken from >FILE or from standard input. > > f wiki list > >Lists all wiki entries, one per line, ordered >case-insensitively by name. > > > you can use 'export' to export a page to a file, edit in emacs (won't work > with anything else ;), then use 'commit' to save the changes. Unfortunate > there's not a direct way to preview changes without saving unless you want > to use the JSON API (which provides "preview" feature for wiki text passed > to it). . . . so basically I need to list wiki pages to figure out what I want, export a page, edit that, then commit it to overwrite what's already there, one file at a time, rather than having a checked out directory of wiki stuff I can just edit and commit as I would a normal set of repository files. Is that correct? It seems cumbersome, but I'll see if it's so cumbersome that I'd rather just use the HTML interface, or whether it actually suits my needs. > > > > have searched through the "fossil help -a" documentation and tried > > searching the fossil-scm website to no avail, making me think this is > > probably not something "possible" with Fossil in its present form. > > It is, but it's not quite like the "embedded docs" feature (which might be > a better fit for you, except that you lose the ability to edit over the > HTML interface). I haven't really looked at the "embedded docs" thing yet to see whether that's something I should be using, but I definitely need the wiki interface for at least some projects, and would like to be able to edit them in much the same way I can edit standard repository files, so the "embedded docs" feature doesn't seem to solve all my problems in this regard. -- 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] wiki edits outside HTML UI
Is there some way to check out the wiki and make edits as one would for standard repository files, to be committed like standard repository files, rather than always having to use a browser to edit the wiki? I have searched through the "fossil help -a" documentation and tried searching the fossil-scm website to no avail, making me think this is probably not something "possible" with Fossil in its present form. -- 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
Re: [fossil-users] Suggestion about fossil commit
On Mon, Apr 14, 2014 at 12:47:11PM -0400, Martin Gagnon wrote: > Le 14 avr. 2014 11:48, "Stephan Beal" a écrit : > > > > But, in my defense, (and I just re-read it to be sure I didn't miss > > it) nowhere in the help documentation (FOSSIL HELP COMMIT) or the > > comment in the editor (# Enter commit message for this check-in. > > Lines beginning with # are ignored.) does it say, or even imply, > > that an empty comment is one of the reasons that will 'abort' the > > commit. > > > > LOL!!! > > If i'm not mistaken, svn does the same thing (but i haven't got an svn > with changes to try it out at the moment). Possibly even git - most > SCMs do not like the users to enter empty commit messages. > > Even the famous CVS does the same... s/famous/infamous/ -- 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
Re: [fossil-users] importing/forking from Git
On Mon, Mar 10, 2014 at 06:31:25PM -0400, Ron Wilson wrote: > On Sat, Mar 8, 2014 at 5:17 PM, Chad Perrin wrote: > > > > Should I take it at this point that --incremental is deprecated and > > should not be used or expected to be present in future Fossil versions? > > So far, I have seen no responses that specifically addressed whether the > > behavior I expected from it was the intended behavior, whether anyone > > else might have the same problem indicating a bug in the software or > > whether this was confined to my situation and thus might be a local > > configuration issue, whether there was anything I could do to provide > > more information to help, and so on. The closest thing to meaningfully > > addressing the issue that I have seen was akin to the old joke . . . > > > > patient: Doctor, doctor, it hurts when I do this! > > doctor: Don't do that. > > I very much doubt that --incremental would be deprecated. I suspect that no > one else has tried your use case. I'm stuck in kind of a no-win situation with this, then. It's not really appropriate to log a bug in an issue tracker without knowing it's a bug, but nobody will tell me if it's a bug, how I should judge whether it's a bug, or whatever else applies here. I'm not even sure yet that what I believe to be expected behavior is expected behavior, or whether I'm just using it wrong. . . . so while I wait to see if someone will give me some guidance, it will fall off everyone's radar, and nothing will be done, so that my only option going forward for some of these projects will be to just use Git. -- 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
Re: [fossil-users] importing/forking from Git
Should I take it at this point that --incremental is deprecated and should not be used or expected to be present in future Fossil versions? So far, I have seen no responses that specifically addressed whether the behavior I expected from it was the intended behavior, whether anyone else might have the same problem indicating a bug in the software or whether this was confined to my situation and thus might be a local configuration issue, whether there was anything I could do to provide more information to help, and so on. The closest thing to meaningfully addressing the issue that I have seen was akin to the old joke . . . patient: Doctor, doctor, it hurts when I do this! doctor: Don't do that. -- 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
Re: [fossil-users] importing/forking from Git
On Wed, Mar 05, 2014 at 07:25:31PM -0500, Ron Wilson wrote: > On Wed, Mar 5, 2014 at 2:21 AM, Chad Perrin wrote: > > > I'm talking about a distributed team, where not everyone has SSH shell > > access or the ability to directly change anything on the filesystem, but > > they all have commit access to a specific set of repositories. This > > means, for instance, that they could clone from, and sync with, an > > existing repository -- but not all could create or delete entire > > repositories. > > > > Presumably the server admin (you?) would be the one creating new > repositories on the server, so would be able to use "fossil clone" or > "fossil import" either via SSH or directly on the server. As I said in another response within this extended thread: . . . there may be a fair number of similar import/fork needs in the future, which means that it makes a lot more sense for me to figure out how to get the import into an existing repository to work -- especially because people who do not have scp access to the server at the moment may also be doing some of this work. If I just do it the way you describe, I would need to do all of this work for every instance, which is not a very reasonable state of affairs here. The result is that, yes, if it was *just me*, and/or I was willing to *do everything all the time*, it would be possible for me to do things in a *more difficult way* every time, but I'm not likely to do any of: 1. give everyone in the world the ability to make these changes on the server directly 2. screw around endlessly with ssh key configuration to limit privileges to a particular set of commands that will probably end up changing regularly so that I have to do that again, then again, and so on 3. do a bunch of extra work on top of extra work other people need to do -- 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
Re: [fossil-users] importing/forking from Git
On Wed, Mar 05, 2014 at 01:40:49AM -0500, Ron Wilson wrote: > On Tue, Mar 4, 2014 at 7:24 PM, Chad Perrin wrote: > > > Both of those solutions would surely work in this case (as long as the > > incremental option works on the server, but not in cases where the same > > would be done by someone with commit access but no SSH filesystem/shell > > access (which is likely in future cases). > > > If you mean using a hosting service, then I would think the service either > provides SSH access or a way transfer existing project repositories to the > service's hosts, possibly providing a means to clone from your local Fossil > repository to the server. I'm talking about a distributed team, where not everyone has SSH shell access or the ability to directly change anything on the filesystem, but they all have commit access to a specific set of repositories. This means, for instance, that they could clone from, and sync with, an existing repository -- but not all could create or delete entire repositories. -- 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
Re: [fossil-users] equivalent to git submodule
On Tue, Mar 04, 2014 at 09:56:31PM -0500, Richard Hipp wrote: > On Tue, Mar 4, 2014 at 9:45 PM, Chad Perrin wrote: > > > Is there a "good" way to do the same thing Git's "submodule" command > > does, to allow multiple repositories to be used to compose a single, > > larger project source tree? > > > > > The only thing (currently) like this in Fossil is the "fossil open > --nested" command, which allows you to create a checkout for repository > nested inside a checkout for another repository. (Normally, if you try to > do "fossil open" while you are within another check-out, the open fails > with an error.) > > A nested check-out does NOT keep track of which versions of which > repositories are associated with each check-in. Nor are there convenient > commands that fetch an automatically open nested check-outs. The only > thing this allows is for you to construct a tree of checkouts. > > But maybe that is enough for what you are trying to do. I dunno Someone I know was asking about it. I wondered if there was more available than --nested for that, for purposes of things like being able to automate cloning of "submodules" or at least getting a canonical list of "submodules" for a project to help keep a distributed team on the same page in terms of managing the whole source tree split across repositories, if only for the purpose of being able to advise my acquaintance intelligently. Thanks. -- 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] equivalent to git submodule
Is there a "good" way to do the same thing Git's "submodule" command does, to allow multiple repositories to be used to compose a single, larger project source tree? From the git-submodule manpage: Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit. They are not to be confused with remotes, which are meant mainly for branches of the same project; submodules are meant for different projects you would like to make part of your source tree, while the history of the two projects still stays completely independent and you cannot modify the contents of the submodule from within the main project. -- 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
Re: [fossil-users] importing/forking from Git
On Tue, Mar 04, 2014 at 07:12:54PM -0500, Ron Wilson wrote: > On Tue, Mar 4, 2014 at 3:43 PM, Chad Perrin wrote: > > > Trying to fork/import from Git is kinda problematic. I started by > > creating a new project on a server: > > > > $ fossil init projectname.fossil > > > > I then cloned locally: > > > > $ fossil clone projectname.fossil > > > > Is there some reason you can't do "fossil clone" on the server? > > Alternately, try: > >$ git fast-export --all |ssh user@server fossil import\ > --git --incremental /path/to/projectname.fossil Both of those solutions would surely work in this case (as long as the incremental option works on the server, but not in cases where the same would be done by someone with commit access but no SSH filesystem/shell access (which is likely in future cases). -- 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
Re: [fossil-users] importing/forking from Git
On Tue, Mar 04, 2014 at 11:16:07PM +0100, Stephan Beal wrote: > On Tue, Mar 4, 2014 at 10:58 PM, Chad Perrin wrote: > > > Is there any chance that Fossil will get a manpage or two at some point? > > > > Perhaps this suffices (or provides a start): > > http://fossil-scm.org/index.html/help > > The /help page can also be accessed locally via (fossil ui). I'm aware of the web help. I'm just wondering about whether it'll ever get a manpage. -- 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
Re: [fossil-users] importing/forking from Git
On Tue, Mar 04, 2014 at 03:49:26PM -0500, James Turner wrote: > On Tue, Mar 04, 2014 at 03:47:31PM -0500, Richard Hipp wrote: > > On Tue, Mar 4, 2014 at 3:43 PM, Chad Perrin wrote: > > > > > Trying to fork/import from Git is kinda problematic. I started by > > > creating a new project on a server: > > > > > > $ fossil init projectname.fossil > > > > > > I then cloned locally: > > > > > > $ fossil clone projectname.fossil > > > > > Doesn't the git import create the fossil repo for you? Maybe you should > try doing the import into a fossil repo that doesn't already exist. According to the "fossil help import" documentation, --incremental should work with an existing Fossil repository rather than creating a new one. > > Then you can scp that repo to your server and clone it down. This is an operation that would be much more convenient to accomplish the way I've already tried to do it, in current circumstances, and there may be a fair number of similar import/fork needs in the future, which means that it makes a lot more sense for me to figure out how to get the import into an existing repository to work -- especially because people who do not have scp access to the server at the moment may also be doing some of this work. If I just do it the way you describe, I would need to do all of this work for every instance, which is not a very reasonable state of affairs here. In any case, I would much rather (help) fix a problem, or learn how to do it right if the error is mine rather than the software's, than just sweep the problem under the rug and use a work-around. -- 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
Re: [fossil-users] importing/forking from Git
The following is based on the fact that I do not know whether there are any undocumented or poorly-documented features that would provide the described functionality, or whether I have simply failed to see what was right in front of my face after spending a fair bit of time staring at Fossil's help output. ## Related Questions Is there some way to merge history from another fossil repository into a brand new fossil repository created with "fossil init" locally? This would help me by allowing me to clone the repository from the server and import from Git to create a new repository, then merge from that new repository into the repository cloned from the server, then push changes to the repository on the server. Is there some way to push from a fossil repository to an arbitrary brand-new repository across HTTP(S)? This would help me by allowing me to import from Git to create a new repository, then simply push from the new Fossil repository to the existing (empty) repository on the server. The ability to do this seems like it would have many, many other potential uses in truly distributed version control workflows, too -- even if it only pushed (with all history) as a branch. Is there some way to create a repository so it does not have a dated "initial commit" just because the init command was used? It seems odd to me that the only DVCS that I have seen that cannot init a repository without an implicit initial commit is Fossil, and this would likely solve my present problem as well. Is there some way to revert the state of an entire repository, involving all files, to an earlier state? It never occurred to me there may not be, and this was obviously part of my earlier attempt to make the import work out for my needs. It seems that the ability to roll back the entire repository to an earlier state should exist for a variety of reasons, perhaps relegating anything undone by the rollback to a dead/closed branch. ## Unrelated Questions Is there any chance that Fossil will get a manpage or two at some point? -- 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
Re: [fossil-users] importing/forking from Git
On Tue, Mar 04, 2014 at 04:01:36PM -0500, Richard Hipp wrote: > I did this: > > mkdir nvi > cd nvi > git clone git://repo.or.cz/nvi.git > cd nvi > git fast-export --all | fossil import ../nvi.fossil > cd .. > mkdir n2 > cd n2 > fossil open ../nvi.fossil > > The result was a directory full of files. And I could do "fossil ui" to > see the complete development timeline, and so forth. My understanding is that "--incremental", as used in my original attempt described in my email to start this thread, should allow me to import into an existing Fossil repository. That is where I am having a problem. Do I misunderstand the intended use of "--incremental"? Is there some way to let someone push from a fresh Fossil repository created by import from git to an existing repository on another server, which I could use instead? The key here is that someone without the ability to brute-force copy (i.e. scp) the projectname.fossil file to the server should be able to import from git then use the fossil utility to push that to a repository on the server, resulting in a repository full of files and history. Is that possible, or do I pretty much need to either throw away all history or just stick with Git instead? -- 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
Re: [fossil-users] importing/forking from Git
On Tue, Mar 04, 2014 at 03:47:31PM -0500, Richard Hipp wrote: > On Tue, Mar 4, 2014 at 3:43 PM, Chad Perrin wrote: > > > Trying to fork/import from Git is kinda problematic. I started by > > creating a new project on a server: > > > > $ fossil init projectname.fossil > > > > I then cloned locally: > > > > $ fossil clone projectname.fossil > > > > I imported from Git: > > > > $ git fast-export --all | fossil import --git --incremental \ > > /path/to/projectname.fossil > > > > I opened the repository: > > > > $ mkdir projectname; cd projectname > > fossil open /path/to/projectname.fossil > > > > The above should be all you need to do. It should just work. And it does > "just work" for every git repository that I've tried, though that is, > admittedly, not that many repos. > > If you are willing to share with us the specific repo you are trying to > import, prehaps the developers can try it and discover what's going wrong. git://repo.or.cz/nvi.git For reference, I'm using . . . $ fossil version This is fossil version 1.28 [3d49f04587] 2014-01-27 17:33:44 UTC . . . on FreeBSD, installed from ports, with the JSON and STATIC options both selected at build time. -- 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] importing/forking from Git
Trying to fork/import from Git is kinda problematic. I started by creating a new project on a server: $ fossil init projectname.fossil I then cloned locally: $ fossil clone projectname.fossil I imported from Git: $ git fast-export --all | fossil import --git --incremental \ /path/to/projectname.fossil I opened the repository: $ mkdir projectname; cd projectname fossil open /path/to/projectname.fossil No files appear. I looked at the timeline: $ fossil timeline === 2014-03-04 === 20:24:06 [178338650a] *CURRENT* initial empty check-in (user: apotheon tags: trunk) === 2013-06-19 === 21:12:33 [34ca661224] === 2011-10-16 === . . . et cetera The obvious choice seems to be to use revert: $ fossil help revert Usage: fossil revert ?-r REVISION? ?FILE ...? Revert to the current repository version of FILE, or to the version associated with baseline REVISION if the -r flag appears. [. . .] Revert all files if no file name is provided. [. . .] I tried that: $ fossil revert -r 34ca661224 the --revision option does not work for the entire tree How do I actually get a repository import to a usable state so I can push it to the server's repository and get on with my life? -- 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
Re: [fossil-users] libfossil script binding docs
On Mon, Feb 24, 2014 at 10:04:33PM +0100, Stephan Beal wrote: > On Mon, Feb 24, 2014 at 9:37 PM, Chad Perrin wrote: > > > Is there some reason this kind of thing shouldn't be maintained in a > > Fossil wiki instead of Google docs? > > > > Yeah, i see the irony in it, but Fossil's just not the tool for what i want > in this case: simplicity and real-time collaboration[1]. i pdate docs with > uncommon frequency (you're just seeing the "public docs" there, not the > associated API docs and the related th1ish docs which get updated as i > find/fix bugs via libfossil), and i'd be firehosing my repos with doc > commits continually were they stored there. Do you plan to move the stuff into a Fossil wiki, eventually? I find Google Docs problematic enough that I typically avoid them -- and, when there's nowhere else to get the information, I just make a local plaintext copy, so I don't have to deal with Google Docs any more than necessary. > > [1] after you've worked in GDocs for long enough you begin to feel that > others can watch everything you type, even outside of gdocs. I agree with Martin G.: that's scary. . . . and if you're using enough Google stuff, some people *are* probably "watching" everything you type (for some definition of "watching" that involves running keyword identifying and text pattern analysis routines). -- 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
Re: [fossil-users] libfossil script binding docs
On Tue, Feb 18, 2014 at 08:55:51PM +0100, Stephan Beal wrote: > Hi, all, > > FYI: the experimental libfossil script bindings have grown somewhat larger > than originally anticipated, and i've started documenting them in a public > Google Doc: Is there some reason this kind of thing shouldn't be maintained in a Fossil wiki instead of Google docs? -- 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
Re: [fossil-users] default web config
On Sun, Jan 19, 2014 at 03:06:42PM -0500, Richard Hipp wrote: > On Sun, Jan 19, 2014 at 2:59 PM, Chad Perrin wrote: > > > Am I missing something? I have not found a simple way to ensure how > > that when I create new Fossil repositories, and I want them all to have > > the web UI settings (CSS, footer, other stuff), I do not have to copy > > and paste stuff into forms in the Fossil web UI admin interface. > > > > > fossil config export skin -R template.repo >desired-appearance.txt > > > fossil new xyzzy.fossil; # Create a new repository > fossil config import -R xyzzy.fossil 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] default web config
Am I missing something? I have not found a simple way to ensure how that when I create new Fossil repositories, and I want them all to have the web UI settings (CSS, footer, other stuff), I do not have to copy and paste stuff into forms in the Fossil web UI admin interface. -- 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
Re: [fossil-users] RFC before trunking 'usage' command
On Sun, Sep 15, 2013 at 01:52:49PM +0200, Stephan Beal wrote: > On Sun, Sep 15, 2013 at 12:56 PM, BohwaZ wrote: > > > provides that, but it's ok as long as it's not turned on by default and > > we can clear the history, like before copying a repository file to > > publish it online. > > > > It's stored in the checkout db, so it's _never_ synced. The '-c' flag > clears the history. My understanding is that the concern raised was about copying (i.e. shell command cp, or maybe scp), not syncing. -- 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
Re: [fossil-users] RFC before trunking 'usage' command
On Thu, Sep 12, 2013 at 12:14:01AM +0200, Stephan Beal wrote: > On Wed, Sep 11, 2013 at 11:58 PM, B Harder wrote: > > > fossil set tracker [on|off] ? > > > IIRC "Trac" was Fossil's predecessor for ticket tracking, and "tracker" > always implies tickets to me (as a by-day/by-night developer). > > How about... > > fossil set nsa-mode on|off If anyone asks, just say "NSA" stands for "Normal Shell Access". Then, to solve the "cmdhist doesn't roll off the fingers naturally" problem, we can use "nsahist", which I think flows a little better when typing. -- 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
Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name
On Thu, Aug 22, 2013 at 08:46:43PM +0200, Stephan Beal wrote: > On Thu, Aug 22, 2013 at 7:30 PM, Chad Perrin wrote: > > > > An acquaintance and I might be able to contribute to it in the meantime. > > > > We're interested in a C API for Fossil being available for > > production use some time in the next year or so, and as such might > > be motivated to hack on it. We'll have to discuss it and let you > > know if we're up for it, if you'd like to see some concerted > > contribution effort from us. > > The only requirement for code submissions is that a license/copyright > waiver be on file with DRH, so that this code can be kept license-clean > vis-a-vis fossil(1) (from which it borrows a huge (and growing) amount of > code). Any sort of assistance, coding or not, is more than welcomed. As far > as "in the next year or so" goes, my very rough guess is that it will take > about until about the end of the year to get most of the fossil(1) > functionality, minus the HTML and networking bits, working at a usable > equivalent level. That might be pessimistic, though: as of a few moments > ago, the formerly-missing low-level pieces of SCM machinery are in place > and working in libfossil. The "verify at commit" bits were just added, > which frees me up to experiment a bit more without concern about completely > breaking my repo during experimentation/testing. Now it's mainly about > tweaking those core APIs and adding the "real" functionality on top of > that. e.g. you can save a wiki page _if_ you know how to brew the secret > sauce (it's not hard, but it's a bit tedious), but the APIs for working > with them at a higher level have yet to be developed (it's an ongoing > process). > > If you decide you'd like to contribute code, the waiver can be found here: > > http://www.fossil-scm.org/index.html/doc/trunk/www/copyright-release.html > > and needs to be snail-mailed to DRH (address is in the form). After discussing this with my collaborator, we'll send those off if we've decided to commit time to working on libfossil. Thanks. -- 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
Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name
On Thu, Aug 22, 2013 at 10:45:08AM +0200, Stephan Beal wrote: > On Thu, Aug 22, 2013 at 4:34 AM, Chad Perrin wrote: > > > > mirror should be set up on GitHub to boost its search engine ranking a > > little bit (with a prominent mention of its canonical version control > > repository being elsewhere using Fossil itself, of course). While > > OMG! lol. It never occurred to me to do such a thing, but you're right, it > would probably be a good idea. I'd like to be kept abreast of how you accomplish that in an automated manner. I too would like to do that with some projects of mine, but it's low enough on the priority list for my own stuff right now that I won't get to it for a while. If you end up doing the hard work of figuring out the best way to do it sooner than I'd get around to even starting, it could save me a lot of effort. It's all about me, after all. > > > > you're at it, if you're willing to bother, you could twit about it on > > Twitter and/or homestead the @libfossil name there. I wouldn't go so > > far as to recommend doing anything on Facebook, of course. > > While i occasionally (or more often) act like one, i don't twit or FB, and > try to keep my G+ to a minimum. It's all too distracting for me - "oh, > something shiny with moving parts..." I try to avoid all those things, myself. For some startup stuff I want to get rolling, I will probably eventually just hire someone to manage the "social networking" crap so I don't have to look at it. > > That said, i do appreciate (==love/hate) the power of marketing and i would > be very appreciative if someone would take over such a role :). How does > the title of PR Manager sound to you :)? . . . kinda like that plea for assistance right there. > > > > I'll see if, at its current level of (in)completeness, it passes muster > > for inclusion in some of the Copyfree Initiative's lists (like copyfree > > licensed projects worthy of support or addition to the copyfree software > > listing), if you want to finally declare an official name for it as > > libfossil. > > Don't bother at this point - it's alpha quality. The basics are in place > and working but there are months of work left in the lib-level SCM-related > components and about a thousand unit tests to write, and then several more > months for things like network sync. i also don't want to propagate the > home page link too much at this point because i will rename the repo as > soon as we decide to settle on the name libfossil ;). Noted. I can be lazy, at your insistence. I'm pretty good at it. > > advantage of having a week off of work, and got far more done on the code > than i had hoped to, but i won't have any more time off until probably > October, so i'm restricted to what i can get done in ~6 hours/night plus > weekends. The point being only that it's moving steadily but not quickly, > and is not something someone will be able to just sit down and use for at > least a few months (and at that point it'll almost certainly be limited to > local usage, but local app-embedded SCM is one of my primary goals here). An acquaintance and I might be able to contribute to it in the meantime. We're interested in a C API for Fossil being available for production use some time in the next year or so, and as such might be motivated to hack on it. We'll have to discuss it and let you know if we're up for it, if you'd like to see some concerted contribution effort from us. -- 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
Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name
On Wed, Aug 21, 2013 at 08:05:58PM -0600, Chad Perrin wrote: > On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote: > > Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw), > > libfossilscm (cc ... -lfossilscm ...) might be next best to > > disambiguate from potential collision w/ another libfossil, though it > > too is pretty ugly looking. > > > > Brief search yields https://github.com/paulfitz/libfossil as second > > hit (after this very discussion). I also searched for libfsl, which > > appears to be claimed, I didn't look into what that project is. > > As it happens, that GitHub hit appears to be someone's work on a library > for Fossil SCM. Glancing across some of the code, it looks like it's a > Ruby libfossil, so there'd be no practical namespace clash -- only a > search engine namespace clash, which is a common case for libraries that > do the same things in different languages anyway. I don't think that's > much of an impediment. It currently has six commits, all from July, > according to GitHub. . . . and I found this on chisel: http://chiselapp.com/user/cutterpillow/repository/fossil-iOS/ There's a libfossil.cpp in the src directory of the source tree (requires anonymous login to view, naturally). That pretty much sums up my findings before web searches start devolving into stuff that doesn't really match, like "ILU.lib - fossil-ice". It appears that all references to libfossil are, in fact, references to libraries related to Fossil SCM, specifically one for Ruby and one for iOS (unless my quick skim of each misinterpreted its purpose). I'd say the name should just be set in stone as libfossil now, and a mirror should be set up on GitHub to boost its search engine ranking a little bit (with a prominent mention of its canonical version control repository being elsewhere using Fossil itself, of course). While you're at it, if you're willing to bother, you could twit about it on Twitter and/or homestead the @libfossil name there. I wouldn't go so far as to recommend doing anything on Facebook, of course. That should about solve any potential namespace issues, by ensuring that other people checking to see if the name is taken will see your project and decide "Yes, it does appear to be taken by an active project." I'll see if, at its current level of (in)completeness, it passes muster for inclusion in some of the Copyfree Initiative's lists (like copyfree licensed projects worthy of support or addition to the copyfree software listing), if you want to finally declare an official name for it as libfossil. -- 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
Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name
On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote: > Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw), > libfossilscm (cc ... -lfossilscm ...) might be next best to > disambiguate from potential collision w/ another libfossil, though it > too is pretty ugly looking. > > Brief search yields https://github.com/paulfitz/libfossil as second > hit (after this very discussion). I also searched for libfsl, which > appears to be claimed, I didn't look into what that project is. As it happens, that GitHub hit appears to be someone's work on a library for Fossil SCM. Glancing across some of the code, it looks like it's a Ruby libfossil, so there'd be no practical namespace clash -- only a search engine namespace clash, which is a common case for libraries that do the same things in different languages anyway. I don't think that's much of an impediment. It currently has six commits, all from July, according to GitHub. -- 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
Re: [fossil-users] Bikeshedding opportunity: back to the topic of "libfossil"'s name
On Wed, Aug 21, 2013 at 07:45:53PM +0200, Stephan Beal wrote: > On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen wrote: > > > > +1 for libfossil. I hate it when libraries have smart names requiring me > > to google for the package name to install. > > BTW (should have noted this earlier): there is a filesystem called > "fossil", and while i have not found a libfossil naming conflict (==cursor > googling), there might potentially be one, which is why i eventually tagged > -scm to the name. But, again, i'm not emotionally attached to that. In > fact, the name doesn't have to contain "fossil", but i assume that'd be > easier for everyone. I definitely vote for the name libfossil. In fact, if you don't use it, I might have to encourage another Fossil library effort just so there's a libfossil that everyone will be able to find and remember. -- 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
Re: [fossil-users] commits from host A sometimes not seen on B
On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote: > On 21 August 2013 05:25, Donny Ward wrote: > > > > I get the same problem every once in awhile. Many times actually. I consider > > myself a heavy fossil user. My most active repository has 1087 checkins all > > made by me. > > > > I once submitted a ticket about it here: > > http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext > > > > ... > > That sounds familiar. For the record, let me say I never (ever) make > branches; all work here is done on trunk. In the repository where a fellow developer and I have seen this problem, there have been no intentional branches made, so add one to the numbers for this condition of the problem arising. > > The ticket you mention is 'fixed' stating a workaround like I did > here; I'm not sure that is how it should be. (Not that reopening the > ticket magically fixes the problem, but you give detailed and probably > useful information there.) Indeed. The "fix" is in the behavior of one person's repository, and not in the intermittently manifesting issue with the operation of Fossil itself. -- 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
Re: [fossil-users] commits from host A sometimes not seen on B
On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote: > > 1) on host S: clone project from host S (http://S/my_repo) > 2) on host C: clone project from host S (http://S/my_repo) > 3) on host C: do some work, and commit changes > 4) on host S, 'fossil up' > 5) on host S: 'fossil timeline' doesn't show the recent commit > 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil > timeline' > 7) on host C: do more work, and commit changes > 8) on host 'S': 'fossil up'; now all recent commits are seen > > Perhaps relevant info: > - autosync=1 on both sides > - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd > - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386 > - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC > - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC Just to add some anecdotal data to this . . . I've seen this behavior recently as well, in very similar circumstances. The major difference has been that both clients have autosync turned off, and do a manual sync before hacking on code, and either a pull before pushing commits or a manual sync. Running "fossil update" after a sync or pull that brings in changes that, in turn, do not show up in the client's checkout directory does not solve the problem, if I recall correctly. It has only happened a couple of times, and both times was fixed by a merge on one side or the other or a reclone. Unfortunately, I have not been able to determine whether any particular pattern of using manual sync or pull has an effect on this. Note that, as I said, it has not happened much, so I have not had much opportunity to identify the conditions specific to the manifestation of the problem with any certainty, apart from what I have mentioned above, which is why I had not composed a question myself about this issue yet. This situation concerns us because the workflow we use may lead to problems if a failure of Fossil to properly deliver commits leads to new code being added in a non-merged way without developers noticing. The server is running Fossil v1.26 (from ports) on FreeBSD 9.0 amd64, one client is running Fossil v1.26 (from ports) on FreeBSD 9.1 amd64, and the other client is running an unknown version of Fossil (from packages) on Arch Linux amd64, I believe, though I will check on the Fossil version when that developer is available and double-check the installed OS with him as well, and share that information if it is deemed relevant. -- 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
Re: [fossil-users] non-cgi path for CGI-based Fossil hosting
On Tue, Aug 20, 2013 at 10:25:05PM +0200, Stephan Beal wrote: > On Tue, Aug 20, 2013 at 10:10 PM, Chad Perrin wrote: > > > Given a shared hosting account where you want to host a Fossil > > repository, where following the directions for CGI-based Fossil hosting > > gives you access to the web UI via example.com/cgi-bin/access_name, I > > would like to know what techniques people use to make it available via > > something like one of the following: > > > > * example.com > > * example.com/access_name > > * access_name.example.com > > # cat .htaccess > Options +ExecCGI +Indexes > > IndexOptions FancyIndexing NameWidth=* > > # doesn't work on my hoster :( AddHandler cgi-script .html > DirectoryIndex index.cgi index.php index.html > > Hope that helps, It does. Thank you. I didn't end up using +Indexes or the IndexOptions, however. -- 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] non-cgi path for CGI-based Fossil hosting
Given a shared hosting account where you want to host a Fossil repository, where following the directions for CGI-based Fossil hosting gives you access to the web UI via example.com/cgi-bin/access_name, I would like to know what techniques people use to make it available via something like one of the following: * example.com * example.com/access_name * access_name.example.com Obviously, in the cgi-bin/access_name example, script that refers to the fossil binary would be called "access_name". Any help would be appreciated. -- 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
Re: [fossil-users] Can I push changed authentication data? c...@apotheon.net exclusive)
On Wed, Aug 14, 2013 at 06:40:51PM -0600, Andy Bradford wrote: > > I thought you already were running the web interface on a private port > that you are tunnelling via SSH? Or do you mean that you'll need to get > familiarized with accessing the web interface? If the latter, disregard > this email. > > Otherwise, the same port that they are tunnelling for cloning/syncing > can be used for tunnelling access to the web interface. All you have to > do is point you browser at the port using the HTTP access method and it > will tunnel through to the fossil server. > > If you setup your tunnel: > > ssh -L :192.168.3.5: fossil@freebsdhost > > After the tunnel is up, you can just point your browser to > > http://127.0.0.1:/ > > And you will be presented with the web ui in your browser. Ah, so I see. I thought I had recalled Dr. Hipp saying something about needing other options for the "fossil server" command to do that. -- 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
Re: [fossil-users] Can I push changed authentication data? c...@apotheon.net exclusive)
On Thu, Aug 15, 2013 at 01:51:15AM +0200, Stephan Beal wrote: > On Thu, Aug 15, 2013 at 12:57 AM, Chad Perrin wrote: > > > I guess I should consider running the web interface too, then, if that's > > the only way to let them change their Fossil passwords. > > > > > Not the _only_ way: > > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.rl2t2hcp6mei > > the JSON API can do that from the CLI. Just pass the JSON parameters in the > from (-p value) on the CLI. I suppose I should have thought about seeing if the JSON API provided a solution to this. Thanks. -- 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
Re: [fossil-users] failure to push/sync
On Thu, Aug 15, 2013 at 02:00:27AM +0200, Stephan Beal wrote: > On Thu, Aug 15, 2013 at 1:34 AM, Richard Hipp wrote: > > > On Wed, Aug 14, 2013 at 5:54 PM, Chad Perrin wrote: > > > >> > >> Is there a complete list of capacities, and what they mean, somewhere? > >> > > > > Go to the Admin/Users page. The capabilities are listed on the right-hand > > side of the page. > > > > You might also find this useful if you're poking around in the fossil code: > > http://fossil-scm.org/index.html/artifact/80a39654ae0bf8a57a6912bf4f37b1a28b6c4dcf?ln=65-90 Thank you both. I use the web interface so rarely that I often just don't even think to look there for something I can't find. -- 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
Re: [fossil-users] Can I push changed authentication data? c...@apotheon.net exclusive)
On Wed, Aug 14, 2013 at 04:31:46PM -0600, Andy Bradford wrote: > Thus said Chad Perrin on Wed, 14 Aug 2013 16:07:02 -0600: > > > Is there another option for this when developers basically do not have > > access to the server where the main Fossil repo is located except by > > way of clone/pull/push/sync? > > Well, technically speaking, they *do* have access to the main Fossil > repo via the tunnel. > > Have them point their browser to http://localhost:/ > > As long as they have the capability to reset their own password, they > can do this on their own. I guess I should consider running the web interface too, then, if that's the only way to let them change their Fossil passwords. -- 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
Re: [fossil-users] Can I push changed authentication data? c...@apotheon.net exclusive)
On Wed, Aug 14, 2013 at 07:56:52PM +0100, fossil@9ox.net wrote: > > Then, looking at help for configuration it seems as though a Push version > is available: > >fossil configuration push AREA ?URL? > > Push the local configuration into the remote server identified > by URL. Admin privilege is required on the remote server for > this to work. When the same record exists both locally and on > the remote end, the one that was most recently changed wins. > Use the --legacy flag when talking to holder servers. This, unfortunately, will not work for my needs, because of the requirement for admin privileges for developers to change their passwords. Without some way for them to set their own passwords, I basically have to set their passwords for them -- which means their passwords will not be private. Even worse, it means that for those who do not (for whatever reason) have email encryption set up, emailing a password for me so I can set it would mean sending it in cleartext. Is there another option for this when developers basically do not have access to the server where the main Fossil repo is located except by way of clone/pull/push/sync? -- 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
Re: [fossil-users] failure to push/sync
On Wed, Aug 14, 2013 at 11:53:41PM +0200, Mark Janssen wrote: > > I am curious how auto sync screws with your workflow. I was of the same > mind in the beginning, always turning of auto sync on my repos. However > these days I always leave it on, I like the extra automatic backup. With a small team, I like being able to make commits locally in fairly small increments of change, which might leave the project in a broken state, so I have relatively fine-grained ability to undo changes. When I get everything to a working state that's ready to share with other developers, then I push it to the main repository. With autosync turned on, though, it'll push to the main repo every time I commit something. -- 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
Re: [fossil-users] failure to push/sync
On Wed, Aug 14, 2013 at 03:38:29PM -0600, Andy Bradford wrote: > Thus said Chad Perrin on Wed, 14 Aug 2013 14:42:02 -0600: > > > Is there some way to give the account write authorization from the > > command line on the server? > > Display: > > fossil user cap foo > > Make foo a ``Developer'': > > fossil user cap foo v Thank you. Is there a complete list of capacities, and what they mean, somewhere? I have yet to find it (and the lack of a manpage makes finding some documentation a bit difficult at times). -- 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] failure to push/sync
I'm seeing some kind of authentication failure when trying to sync local with remote over SSH. Given a user account "foo": $ fossil clone http://foo@127.0.0.1:/test test.fsl password for foo: remember password (Y/n)? n Round-trips: 1 Artifacts sent: 0 received: 0 *** time skew *** server is fast by 20.4 seconds Round-trips: 2 Artifacts sent: 0 received: 1 *** time skew *** server is fast by 20.3 seconds Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 540 bytes sent, 1162 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 4f2339b57d865b43d48c3c6dccd0f989f0544860 admin-user: foo (password is "eba680") foo@glaze:/usr/home/foo/tmp/shared $ cd ../src/test/ foo@glaze:/usr/home/foo/tmp/src/test $ fossil open ../../shared/test.fsl foo@glaze:/usr/home/foo/tmp/src/test $ echo '# DO NOT READ ME' > README foo@glaze:/usr/home/foo/tmp/src/test $ fossil add README ADDED README foo@glaze:/usr/home/foo/tmp/src/test $ fossil commit -m 'added README' Autosync: http://foo@127.0.0.1:/test Round-trips: 1 Artifacts sent: 0 received: 0 missing or incorrect password for user "foo" foo@glaze:/usr/home/foo/tmp/src/test $ fossil setting autosync off foo@glaze:/usr/home/foo/tmp/src/test $ fossil commit -m 'added README' New_Version: 2360769f27be6e03e22dcec699200ca10383adb5 foo@glaze:/usr/home/foo/tmp/src/test $ fossil push password for foo: remember password (Y/n)? n Push to http://foo@127.0.0.1:/test Round-trips: 1 Artifacts sent: 2 received: 0 Error: not authorized to write Round-trips: 1 Artifacts sent: 2 received: 0 Push finished with 548 bytes sent, 277 bytes received So . . . I'm guessing the autosync fail is due to it assuming the local Fossil admin user's password being randomly set at the time the repository is cloned, easily solved by turning off autosync (which I don't want on for this anyway -- it would really screw with workflow). It still fails after that, though, with an authorization error: Error: not authorized to write Is there some way to give the account write authorization from the command line on the server? I don't see anything in the output of "fossil user help", and what I've found about this error in web searches doesn't seem to apply to my case (involving mismatched Fossil versions, for instance). -- 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] Can I push changed authentication data?
I'm guessing the answer to this is "no", but guessing isn't always good enough. Let's say you have cloned a Fossil repository from a remote repository, then you use "fossil user password" to change the password for your user account on the local repository, then sync with the remote repository. Is there some way to push the changed password to the remote repository so that it will be the Fossil repository password you'd use for that account next time you sync? -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Wed, Aug 14, 2013 at 07:33:55AM +0200, Gour wrote: > On Tue, 13 Aug 2013 18:21:06 -0600 > Chad Perrin wrote: > > > First . . . I misspoke. It was lighttpd that I was thinking of using, > > not thttpd. > > > > Second . . . Hiawatha doesn't meet my requirements for any project in > > which I've considered various webserver options, so I've never used > > it, so I for one don't really have much to say on the subject. > > That's interesting, I'm just curious what do you find missing in > Hiawatha to consider lighttpd instead? My requirements tend to include one of two of the following: 1. Apache. Sometimes, for some reason, Apache is all that will do. 2. Lightweight and copyfree licensed. Hiawatha is distributed under the terms of the GPLv2, which is a copyleft license, not a copyfree license. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Tue, Aug 13, 2013 at 07:02:52PM -0600, Andy Bradford wrote: > Thus said Chad Perrin on Tue, 13 Aug 2013 18:39:21 -0600: > > > Everything was working great until I tried to use the following in the > > authorized_keys file for the user account hosting the Fossil repos: > > > > command="/usr/local/bin/fossil",no-X11-forwarding,no-agent-forwarding > > ssh-rsa @ > > This won't really work at all with the current release of fossil > (version 1.26) because fossil's client side expects to be able to talk > to a shell, not to a fossil program. > > > . . . because, of course, "ssh -L" is then prevented from working. > > That shouldn't have prevented port forwarding. no-port-forwarding is > what prevents that and I don't see that listed. More than likely what > happened is that the SSH connection brought up fossil, but it gave you > a usage statement. > > > > Is there a fairly simple way to prevent people from doing anything > > unrelated to what a dev team member should be able to do that still > > allows me to use this approach to granting encrypted Fossil access? > > Well, if you are doing the port forwarding approach, yes, there is. Make > the command something like sleep: > > command="/bin/sleep 28800" ssh-rsa ... Ahh, of course. I'm kind of an idiot today. What I need is a harmless command that prevents the user from doing anything else on the system in the shell, not the fossil command. Thanks. I'll see if I can come up with something that'll work "indefinitely", and in the meantime use sleep. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 07:45:16PM -0600, Andy Bradford wrote: > 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 in a directory hierarchy, but let's keep things > > simple for now.) > > > > (2) Run "fossil server -port /home/fossil/repos" > > Instead, do steps 1 and 2. At this point, the user should do: > > ssh -L :127.0.0.1: freebsdhost > > And then they can clone from there: > > fossil clone http://user@127.0.0.1:/project > > This will encrypt the connection from their PC to freebsdhost. It will > not have encrypted communication on port , but the traffic is all on > localhost. > > > With the SSH changes I've been working it steps 1 and 2 are not required > and they can clone this way instead: > > fossil clone -l username ssh://fossil@freebsdhost/repos/project.fossil > project.fossil Everything was working great until I tried to use the following in the authorized_keys file for the user account hosting the Fossil repos: command="/usr/local/bin/fossil",no-X11-forwarding,no-agent-forwarding ssh-rsa @ . . . because, of course, "ssh -L" is then prevented from working. Is there a fairly simple way to prevent people from doing anything unrelated to what a dev team member should be able to do that still allows me to use this approach to granting encrypted Fossil access? -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Tue, Aug 13, 2013 at 07:19:10AM +0200, Gour wrote: > On Mon, 12 Aug 2013 18:15:37 -0600 > Chad Perrin wrote: > > > I'm actually leaning more toward thttpd now, anyway. > > I'd also like to be able to use Fossil with e.g. FastCGI and wonder what > do you think about Hiawatha (http://www.hiawatha-webserver.org/) web > server which is my preferred choice for running PHP stuff? > > It seems to be quite secure and it *might* be interesting for Richard... First . . . I misspoke. It was lighttpd that I was thinking of using, not thttpd. Second . . . Hiawatha doesn't meet my requirements for any project in which I've considered various webserver options, so I've never used it, so I for one don't really have much to say on the subject. -- 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
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 02:58:56PM -0600, Andy Bradford wrote: > > Hopefully that clarifies. Yeah . . . especially considering I thought he was referring to problems with the approach I am using right now, rather than the approach you're developing, when he started talking about logging issues. I'm pretty clear on how things work with regard to logging now, for both SSH scenarios, at any rate. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 06:25:11PM +0200, Stephan Beal wrote: > On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp wrote: > > On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal wrote: > >> > >> That wasn't terribly clear. FastCGI basically starts 1 instance of the > >> app and keeps feeding it new data for each request. Fossil's structure does > >> not allow it to do that. > >> > >> > > Does too. > > > > For Fossil to run FastCGI/SCGI, all that is needed is another command > > similar to "fossil server" or "fossil ui". The "fossil server" listens for > > incoming HTTP requests and responds separately to each request. A "fossil > > fastcgi" or "fossil scgi" command would do basically the same thing, except > > that it would interpret the FastCGI or SCGI wire protocol rather than HTTP. > > > > It _can_ do that but that negates the benefit of using fastcgi because > fossil ends up forking anyway. It's not much of a benefit if the alternative is that you can't use Fossil with that particular webserver anyway. If I chose to use nginx, the reason wouldn't be to prevent myself from using CGI. Of course, that's speaking from the perspective of what I'm trying to do. Your own circumstances, as you described in parts of the email I snipped out, were apparently more about specifically wanting FastCGI. I'm actually leaning more toward thttpd now, anyway. Of course, setting up a webserver that would interact with Fossil is somewhere in the future at the moment, and it's not really a critical decision at this time. -- 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
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote: > On 2013-08-11 14:49, Chad Perrin wrote: > > > > Err . . . wait. Is it not logging the *user*, or just the IP address? > > What would it log in place of the actual authenticated Fossil user > > account that initiated the sync? > > The user in the current ssh functionality is not authenticated against > fossil. Ah, okay. I thought you meant the Fossil user account for a moment there. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 03:20:14PM +0200, Stephan Beal wrote: > On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal wrote: > > > > Fossil is not fastcgi-compatible. i tried to get it working a few years > > ago but fastcgi requires that each execution of the app has a clean > > starting state, and fossil's app is built to work only for a single > > execution. > > That wasn't terribly clear. FastCGI basically starts 1 instance of the app > and keeps feeding it new data for each request. Fossil's structure does not > allow it to do that. Well . . . that'd definitely change how I would want to do things, then. Now that I think about it, though, I'm not sure I'd want to go the CGI route if I needed a whole separate webserver, anyway. -- 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
Re: [fossil-users] ssl implementation
Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the "thanks" is my general response for everything to which I do not specifically respond below. Specific comments follow. On Sun, Aug 11, 2013 at 01:21:37PM +0200, Rene wrote: > On 2013-08-10 04:21, Chad Perrin wrote: > > On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: > > > > The reason I choose axTLS > > > > . . . snip . . . > > > > > > If this is of interest I can add it on a branch. > > > > I find it pretty interesting. The biggest problem I see with axTLS is > > the protocol support limitation you identified. > > > > Are there good howtos for using axTLS out there on the web somewhere? > > No there isn't. I used the information from http://axTLS.sf.net to > create the fossil interface. I hadn't been able to find any. I'm glad it's not just me who couldn't find them, but at the same time bummed that it means you can't suggest any for me. Bit of a quandary, there. > > Having read your question about team setup on freebsd, My recommendation > is to go with ssh keys. That's my plan. My interest in axTLS is actually mostly unrelated to Fossil, though I support there being options other than OpenSSL or GnuTLS. In fact, both OpenSSL and (especially) GnutTLS have license compatibility problems that frankly annoy the crap out of me, and axTLS licensing neatly solves that if it also solves the technical needs of a project. > Much simpler provided that all you need/want is cmdline access. > With the standard ssh functionality you can get by. The only minor thing > in that setup is that the log is not recording the user that did > clone/sync/pull/push but the fossil owner. I quess that is easy enough > to fix. But do use forced commands otherwise people can gain access to > the fossil account. If you so wish to prevent logins. Or prevent logins > by using the shell /bin/nologin. Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 11:40:34PM -0600, Andy Bradford wrote: > Thus said Chad Perrin on Sat, 10 Aug 2013 20:07:41 -0600: > > > > 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, > > though if any more informative replies come through I'll of course > > learn from them as well. > > By the way, if you do it this way, all IP addresses logged with commits > to your fossils will appear to come from 127.0.0.1 and not from the > actual SSH client that is being used to access it. This may or may not > be important to you. It should still log Fossil usernames though -- right? If so, that'll do, at least for now. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 12:43:24PM +0200, Eduardo Morras wrote: > On Sat, 10 Aug 2013 20:07:41 -0600 > Chad Perrin wrote: > > > Dr. Hipp's series of suggestions have, of course, also been informative > > for me, and while I do intend to expand capabilities to the point where > > a separate webserver (probably nginx) is involved for some purposes as > > described in one of his replies, for now I just need something quick, > > effective, and secure to get some projects underway. > > Nginx doesn't support cgi, and as its developers says, it will never have cgi > support. . . . but you can use fastcgi with nginx. Is that not good enough for Fossil? -- 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
Re: [fossil-users] self-hosted Fossil for a team
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 answers (among other reasons for double-checking). I've got things working well enough on the server right now that I should be able to just add some configuration to allow the other team members access and all will be well, which I'll probably do first thing Monday. I appreciate all the help I've received, getting to this point. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 08:16:15PM -0600, Andy Bradford wrote: > 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 repositories just for purposes of testing stuff. > > There's not really a chance that it will screw up the repositories, but > you certainly should use it on test repositories if you're concerned. I > use it daily and all it changes is the way that the fossil client > communiates with the ``fossil server'' on the remote side. > > Because all communication happens via the standard ``fossil http'' > interface, it is unlikely that the remote repository will get broken. > > It's mostly ready to be used except for a few minor interface issues > that I'm not completely satisfied with, which I mentioned. Specifically, > how does the fossil client decide when to use a Fossil username and when > to prompt for a password? > > You're feedback would be much appreciated. Great. I'll try to find time to get something set up in the near future to do some user testing and give feedback, then. > > Regarding the ``quickest way'' to get your environment setup, please see > my last response. You can easily tunnel over SSH if you are willing to > run ``fossil server'' on the freebsdhost and train your users how to use > SSH tunnels. You could then setup keys that don't provide shell access > which merely act as a way to get the SSH tunnel established. The team members are bright people and understand Unixy stuff pretty well. It shouldn't be a problem. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 08:45:31PM -0400, Richard Hipp wrote: > On Sat, Aug 10, 2013 at 8:07 PM, Chad Perrin wrote: > > (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 in a directory hierarchy, but let's keep things simple for > now.) 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? > > (2) Run "fossil server -port /home/fossil/repos" > > (3) Users connect to "http://freebsdhost:/repo"; where "freebsdhost" is > the name of your server obviously, and where "repo" is the name of one of > your repositories with the ".fossil" suffix omitted. > > Additional Notes: > > * You can use whatever TCP port you want in place of . > > * If you run the "fossil server" command as root, and if the directory > containing repository files (and the repo files too) are owned by some > non-root user, then Fossil will fork a copy of itself for each inbound > request and put itself into a chroot jail as the user who owns the > directory, before reading anything off of the wire. I read this as saying that the incoming requests will then only interact with chrooted forks that are owned by an unprivileged user account on the system. Is that correct? Is there any reason to expect things may not work as expected on FreeBSD (considering I suspect most of the devs use Linux-based systems)? Does it do all that without any additional configuration of Fossil itself, the specific repository, or the host system? Thanks for all your help. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 07:45:16PM -0600, Andy Bradford wrote: > 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 in a directory hierarchy, but let's keep things > > simple for now.) > > > > (2) Run "fossil server -port /home/fossil/repos" > > Instead, do steps 1 and 2. At this point, the user should do: > > ssh -L :127.0.0.1: freebsdhost > > And then they can clone from there: > > fossil clone http://user@127.0.0.1:/project > > This will encrypt the connection from their PC to freebsdhost. It will > not have encrypted communication on port , but the traffic is all on > localhost. > > > With the SSH changes I've been working it steps 1 and 2 are not required > and they can clone this way instead: > > fossil clone -l username ssh://fossil@freebsdhost/repos/project.fossil > project.fossil 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, though if any more informative replies come through I'll of course learn from them as well. Dr. Hipp's series of suggestions have, of course, also been informative for me, and while I do intend to expand capabilities to the point where a separate webserver (probably nginx) is involved for some purposes as described in one of his replies, for now I just need something quick, effective, and secure to get some projects underway. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 07:20:11PM -0600, Andy Bradford wrote: > Thus said Chad Perrin on Sat, 10 Aug 2013 18:07:28 -0600: > > > What's the quick/easy way to get Fossil set up so a small team can > > push/pull/sync multiple Fossil repositories on the server without > > having shell accounts? > > At the moment, this type of SSH integration isn't as flexible as it > could be because Fossil depends on the shell behaving in certain ways. > I've been working on making it easier to use fossil in an SSH > environment, and have had a few iterations. > > I would appreciate your feedback regarding how my changes currently > work. You can pull the latest iteration from here, which you'll have to > build from sources: > > http://www.fossil-scm.org/index.html/info/0c19424325 . . . snip . . . > > At the moment, this is experimental code and a work in progress This, unfortunately, kinda makes it probably a bad idea for the purposes for which I asked for some help. On the other hand, I would like to help accelerate development of this functionality, and if I can do so by testing I will try to find time to do so. I'll just do so separately from the team access I need to provide right now. 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 repositories just for purposes of testing stuff. Thanks for the help. Your comment in another thread (to which I will reply shortly) actually describes what I will probably do for the distributed team's needs, for now. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sun, Aug 11, 2013 at 02:34:55AM +0200, Jan Danielsson wrote: > On 8/11/13 2:07 AM, Chad Perrin wrote: > > So . . . let's say I have a server (running FreeBSD, and I'll probably > > be setting this up in a jail) and a router that can forward ports > > (already has SSH forwarded to this server). For argument's sake, let's > > say we're confined to only one port per protocol. What's the quick/easy > > way to get Fossil set up so a small team can push/pull/sync multiple > > Fossil repositories on the server without having shell accounts? The > > connection should be encrypted so that nobody can sniff usernames and > > passwords when people are syncing, the users should preferably all be > > using different credentials (not the same username/password combination, > > in other words), and I should not have to pay any money to any third > > parties (ISPs, certifying authorities, et cetera) as part of this. > >I have been using a combination of self-signed certificates, apache > and fossil for a long time and have been very happy with it. (Apache is > configured to only allow connections with full certificate chain > verification). > >apache is configured to set REMOTE_USER to the CN-field of the > certificate's subject, and the fossil repository is configured to get > username from REMOTE_USER. So the only thing the users need to do is to > place the CA, their certificate and key in a Good Place, and then set up > fossil to use them. If the users will be accessing the web ui via a > web-browser they will need to make the appropriate configurations to > their web browsers as well. > >The users don't have to enter a password other than to unlock their > local private key. (As a matter of policy; if they have the key on > encrypted partitions they don't even have to do that). > >I use apache's access management tools to configure which > users/groups can access which repositories. Much of this does not appear immediately necessary to using only the command line interface on the team member's workstation or laptop to sync with a repository on the server, thus making it look like significantly more of a solution than I need. Am I mistaken? > >The only part of the whole configuration which I found to be annoying > was the generation of certificates/keys (the openssl command line tool > and online manual is at times very unfriendly). Other than that, it was > pretty much a breeze. > >If this is something you're interested in, then I can post more > detailed instructions on how to set it up. I am interested for future needs, even if this is not really a quick/easy way to accomplish what I need right now. -- 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
Re: [fossil-users] self-hosted Fossil for a team
On Sat, Aug 10, 2013 at 08:45:31PM -0400, Richard Hipp wrote: > On Sat, Aug 10, 2013 at 8:07 PM, Chad Perrin wrote: > > > > So . . . let's say I have a server (running FreeBSD, and I'll probably > > be setting this up in a jail) and a router that can forward ports > > (already has SSH forwarded to this server). For argument's sake, let's > > say we're confined to only one port per protocol. What's the quick/easy > > way to get Fossil set up so a small team can push/pull/sync multiple > > Fossil repositories on the server without having shell accounts? > > > (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 in a directory hierarchy, but let's keep things simple for > now.) > > (2) Run "fossil server -port /home/fossil/repos" > > (3) Users connect to "http://freebsdhost:/repo"; where "freebsdhost" is > the name of your server obviously, and where "repo" is the name of one of > your repositories with the ".fossil" suffix omitted. If I'm not mistaken, this will *not* in fact use an encrypted connection to protect logins from network sniffing (such as when working from a coffee shop wireless network) for syncing with the command line interface of Fossil SCM. Is that correct? If so, I'm afraid that is not going to work for my needs. I am curious about some of the other things you mentioned in the email, and would like to look into them and perhaps ask more questions about them, but for now I want to focus on whether this solution is actually suitable to my needs at all. Thank you for the prompt response. -- 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] self-hosted Fossil for a team
So . . . let's say I have a server (running FreeBSD, and I'll probably be setting this up in a jail) and a router that can forward ports (already has SSH forwarded to this server). For argument's sake, let's say we're confined to only one port per protocol. What's the quick/easy way to get Fossil set up so a small team can push/pull/sync multiple Fossil repositories on the server without having shell accounts? The connection should be encrypted so that nobody can sniff usernames and passwords when people are syncing, the users should preferably all be using different credentials (not the same username/password combination, in other words), and I should not have to pay any money to any third parties (ISPs, certifying authorities, et cetera) as part of this. I've been playing with this a bit on the internal network for a couple days, but I haven't come up with anything that really satisfies me yet. Any help would be appreciated. -- 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
Re: [fossil-users] ssl implementation
On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: > > The reason I choose axTLS . . . snip . . . > > If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? -- 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
Re: [fossil-users] simple Fossil For New Users intro guide
On Fri, Aug 09, 2013 at 12:17:00PM -0400, David Mason wrote: > The more newbie help the better... I - for one - certainly appreciate it. I wrote a set of notes years ago covering the issues described in this guide, as reminders for myself. I kept meaning to flesh it out a bit and post it online, but never got around to it until yesterday -- and then only because an acquaintance needed the help this could provide, so I updated the notes (it had gotten a bit out of date with the current state of affairs in Fossil SCM land), filled in a bunch of explanatory text, and finally posted it. If it helped me when I wasn't yet used to Fossil, and helped this acquaintance of mine, I figured it might help others as well. -- 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
Re: [fossil-users] simple Fossil For New Users intro guide
On Fri, Aug 09, 2013 at 12:15:57PM +0200, Michai Ramakers wrote: > On 8 August 2013 22:25, Chad Perrin wrote: > > This "Fossil For New Users" intro to doing the basics in Fossil was a > > few minutes' work, in part as a reminder for myself. I thought it might > > be useful for others as well, though, so I finally decided to put it > > online. > > > > http://blogstrapping.com/?page=2013.220.13.42.53 > > Not much constructive criticism from me, but instead let me say this > looks good and useful. Minimal workflow and pointers where to go from > here. I like the verbatim command-line dialog as well. Thanks. > > If you want, you might - as an advertisement tool so to say - point > the user towards the Fossil main site (why isn't there a link > already..?) and mention early in your text that this is a self-hosting > repository. (Being able to see how it works hands-on was a big reason > for me giving it a try.) I meant to add a link to the main site at the beginning, and it just completely slipped my mind. Thanks for reminding me. > > In section 'Managing Project Files', you have 'fossil status' twice in > a row, btw. . . . and that has been fixed as well. It was an artifact of editing, I think. Unlike Fossil, I'm afraid I am not transactional. -- 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
Re: [fossil-users] simple Fossil For New Users intro guide
On Thu, Aug 08, 2013 at 10:48:36PM +0200, j. van den hoff wrote: > > 1. > the "Unlike most popular DVCSes..." is a bit misleading. all of them have > a database for each checkout, of course, but not in a single file. backing > them up is not really that much more complicated. I would try to emphasize > a bit more that the difference is indeed that fossil uses a "monolithic" > database, i.e. a single file instead of a directory tree and that has > indeed some advantages if you only use `cp' since you don't run into > permission issues. I was trying to point out the distinction between the checkout and the repository file -- not to say that Git (for instance) doesn't have any "database" of version control. I tried to clarify the text, though, without overcomplicating things, given the very simple approach I'm trying to maintain. > > 2. > I'm not comfortable with categorically recommending to new users to > separate the database from the checkout. I know that many on this list > think this to be a good thing but in general (as opposed to "for special > use cases") I don't think there is any advantage. keeping the database > within the checkout (just as the others (git, hg, bzr, ...) do, has > advantages, too (e.g. ability to move the whole thing around without > closing/reopening the repo) and also allows to identify a checkout as > being (or having been) under fossil control even when the repo is > closed. so, I would mention both possibilities as being equally > viable and it being mostly a matter of taste which to choose. (e.g., > my preference is to put all the databases with a default name into > the checkout dir (I use `.fslrepo') and put the "server-side clones" > in a common location/directory. that works very well for me and would > indeed not recommend to locally separate the databases from their > checkouts). I don't want to turn the thing into a book-length exploration of all the options. It's meant to get people started quickly, and little else. I did rearrange things slightly in that paragraph to make it clearer that I did not intend a categorical imperative (apologies to Kant for abusing the term), but I did not add any digressions about the relative merits and flaws of differing approaches, which is better saved for other resources than mine. Hopefully this addresses your concerns. I appreciate the feedback. -- 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] simple Fossil For New Users intro guide
This "Fossil For New Users" intro to doing the basics in Fossil was a few minutes' work, in part as a reminder for myself. I thought it might be useful for others as well, though, so I finally decided to put it online. http://blogstrapping.com/?page=2013.220.13.42.53 Let me know what you think. If there are any problems I'll try to fix them. -- 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
