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 "bless" a certain syntax highlighting library and
> forgo a
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();
> +
> +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 <d...@sqlite.org> 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 <c...@apotheon.net> 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" <sgb...@googlemail.com> wrote: > > On Sat, Dec 24, 2016 at 6:42 PM, Chad Perrin <c...@apotheon.net> 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
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 c...@apotheon.net 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 varro@nodomain.invalidwrote: 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 06:04:18PM +0200, Stephan Beal wrote: On Wed, Apr 23, 2014 at 6:00 PM, Chad Perrin c...@apotheon.net 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
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 sgb...@googlemail.com 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:36:38PM +0200, Stephan Beal wrote: On Wed, Apr 23, 2014 at 6:29 PM, Chad Perrin c...@apotheon.net 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 12:52:36PM -0400, Richard Hipp wrote: On Wed, Apr 23, 2014 at 12:50 PM, Chad Perrin c...@apotheon.net 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] 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 sgb...@googlemail.com 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 c...@apotheon.net 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 c...@apotheon.net 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 Tue, Mar 04, 2014 at 03:47:31PM -0500, Richard Hipp wrote: On Tue, Mar 4, 2014 at 3:43 PM, Chad Perrin c...@apotheon.net 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 u...@uri.for/projectname/index.cgi 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
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
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 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 c...@apotheon.net 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 u...@uri.for/projectname/index.cgi 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
On Tue, Mar 04, 2014 at 11:16:07PM +0100, Stephan Beal wrote: On Tue, Mar 4, 2014 at 10:58 PM, Chad Perrin c...@apotheon.net 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 07:12:54PM -0500, Ron Wilson wrote: On Tue, Mar 4, 2014 at 3:43 PM, Chad Perrin c...@apotheon.net 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 u...@uri.for/projectname/index.cgi 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
[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] 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 c...@apotheon.net 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
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 c...@apotheon.net 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] 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
[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] 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 c...@apotheon.net 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 desired-appearance.txt Excellent. Thank you. I knew I'd feel dumb when I got the answer. . . . -- 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 boh...@bohwaz.net 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 brad.har...@gmail.com 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 c...@apotheon.net 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] 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] 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 donnyjw...@gmail.com 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] 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 mpc.jans...@gmail.com 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] 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 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
[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] 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 c...@apotheon.net 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 IfModule mod_autoindex.c IndexOptions FancyIndexing NameWidth=* /ifModule # 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
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 c...@apotheon.net 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] 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
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] 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] 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] 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 d...@sqlite.org wrote: On Wed, Aug 14, 2013 at 5:54 PM, Chad Perrin c...@apotheon.net 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 Thu, Aug 15, 2013 at 01:51:15AM +0200, Stephan Beal wrote: On Thu, Aug 15, 2013 at 12:57 AM, Chad Perrin c...@apotheon.net 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] 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] 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 c...@apotheon.net 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] 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 key user@client-host . . . 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 Sun, Aug 11, 2013 at 06:25:11PM +0200, Stephan Beal wrote: On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal sgb...@googlemail.comwrote: 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 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 12:43:24PM +0200, Eduardo Morras wrote: On Sat, 10 Aug 2013 20:07:41 -0600 Chad Perrin c...@apotheon.net 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
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] 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] 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 Sat, Aug 10, 2013 at 08:45:31PM -0400, Richard Hipp wrote: On Sat, Aug 10, 2013 at 8:07 PM, Chad Perrin c...@apotheon.net 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
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 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 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 08:45:31PM -0400, Richard Hipp wrote: On Sat, Aug 10, 2013 at 8:07 PM, Chad Perrin c...@apotheon.net 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 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
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] 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
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 c...@apotheon.net 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 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
[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
[fossil-users] custom priorities in ticket system
How would I go about adding a blocking severity or priority to Fossil's ticketing system (aka bugtracker)? Is there some other approach to solving the problem of identifying an issue as blocking that people use, that has not occurred to me? -- 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] JSON API docs
What's the current canonical location of documentation for Fossil's JSON API? Are there some handy howtos, tutorials, examples, or other third-party sources of documentation for the JSON API? -- 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] Did you know that Fossil could do...
On Tue, May 28, 2013 at 09:08:10AM -0400, Richard Hipp wrote: Survey: How many people know that in the web-based timeline for Fossil, you can click on any two nodes in the graph and get a diff between those two nodes? I think this is a very useful feature. But I'm guessing that not many people know it exists. Please confirm or refute my guess. And assuming I'm guessing correctly, do you have any suggestions on how I can get the word out about this and other useful but obscure features of Fossil? Maybe this will help a little bit: https://twitter.com/CopyfreeNews/status/339811545045417984 -- 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] JSON API docs
On Wed, May 29, 2013 at 10:23:50PM +0200, Stephan Beal wrote: On Wed, May 29, 2013 at 7:41 PM, Chad Perrin c...@apotheon.net wrote: What's the current canonical location of documentation for Fossil's JSON API? Are there some handy howtos, tutorials, examples, or other third-party sources of documentation for the JSON API? The current location of the API docs, updated as the code is updated: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view Thanks. For some reason, I had the impression that might be out of date and/or no longer the canonical location. I think I had some vague recollection of the docs being moved to a wiki somewhere from earlier list traffic, but didn't find it in my email archives. I guess I was mistaken. -- 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] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 05:13:24PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: zsh: sports metaphor not found Sorry, I was attempting to inject some humor into this discussion because it has grown very tedious. I guess you didn't find my rejoinder amusing. HDDs also suffer wear and tear during I/O operations, and new SSDs easily last long enough that, relative to HDDs, this should no longer be any kind of problem. In fact, the major problem is not that SSDs have a limited number of writes; so do HDDs. The problem is that you can know in advance how many you have, while with HDDs it's a roll of the dice. My original point of doing (potentially several GB of) superfluous file I/O still stands. . . . unless you pay attention to what I said. It's not just bikeshedding if it's a matter of actual tool usability. Funny, I've been using Fossil for years and this usability problem has never bothered me. In fact, quite the opposite. The point has been made many times that the usability issue under discussion is relevant to certain people, while certain others may not experience the same issue. The question under discussion is how to determine which is the more important group to satisfy, which to some extent involves an estimate of numbers. Considering the number of new users who have not yet started using Fossil but might some day, and who are quite familiar with both Unix environments and other VCSes newer than CVS, combined with the number of current users who find the current behavior of `mv` and `rm` somewhat confounding, is surely much greater than the number of people currently using Fossil who never encounter other VCSes and Unix environments to give a crap, I fall on the we should change things side of the debate. . . . which works great for new users! Oh, wait, no it doesn't. There is always a learning curve for new users, however slight. I suppose that means we should make the curve as steep as possible, regardless of whether it actually buys us anything, then. Right? If they can't hack it, let them use rcs instead. They can eat cake while they're at it. I've read them all. It was easy. I didn't want to read them all. Okay. Why didn't you say so in the first place? Because *you* never really interact with the rest of the world, the fact the rest of us do is irrelevant, I guess. It's all about you. I'm growing increasingly tired of your attempts to insult me. That's not an insult. It's marveling at your egocentric dismissal of everyone in the world with a different computing experience than you, which some of the rest of us might find insulting if we were as thin skinned as you. Your lack of experience with those other systems does not in any way invalidate the question. I never stated that I lack experience with those other systems; however, I use them only very rarely. That's a lack of experience, just as a trial lawyer of twenty years would refer to my involvement in Youth In Government twenty years ago in the trial law part of the program as a lack of experience. I don't really consider occasional dilettentes experienced in a significant sense. Really, I think the thing that irks me most about many of the arguments on your side of the debate is their condescending dismissal of the possibility that someone might have a meaningful argument for changing the behavior of `mv` and `rm` Fossil commands, even if it is not deemed compelling enough to change things by core contributors. In previous emails, by contrast, I have tried to address concerns of those who disagree with me on the overall desirability of the proposed changes by suggesting deprecation followed by eventual change in accord with semantic versioning. Others have made similar suggestions to try to satisfy everyone involved. You, meanwhile, have taken the position of Screw you and the horse you rode in on; you can have some other command instead that doesn't actually address core concerns you've raised. Perhaps you should think about that before blowing people's concerns off as meaningless and accusing them of insulting you. Even if someone has insulted you, that doesn't justify your own insulting lack of regard for anyone who might not have exactly the same software usage habits as you. -- 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] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. I help write the bleeding edge versions. Therefore, it is useful that I run them on a daily basis as well. . . . therefore, I don't see the problem. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. I would just like to point out here that, contrary to your assertion to the contrary, I do care about other people besides myself in this matter. I'd call it a suggestion, rather than an assertion. I don't think I quite explicitly made that charge. It's nice to know you care, though. Perhaps you'd like to acknowledge that fact in future comments rather than phrase your commentary like that two which I responded. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. It's very subtle, but it's there. To quote, someone who will never pay attention to warnings. Out of curiousity, how many warnings given by software do *YOU* routinely ignore (e.g. web site security, etc)? Someone who will never pay attention to warnings isn't a demonization. It's a characterization of people who, well, never pay attention to warnings -- which, you may note, was obviously not directed at you personally, in any case. There are people out there who never pay attention to warnings, and people who use four-year out of date software with critical security vulnerabilities left unpatched. Screws fall out all the time. The world is an imperfect place. Please tell me who else would not notice warnings over a gentle deprecation period with warnings other than: 1. those who never pay attention to warnings 2. those who go for ridiculously long times without updating software I'm willing to acknowledge the existence of people in large numbers falling through that crack if you can point out such a crack through which large numbers of people might fall. The world is, after all, an imperfect place (see above). I just see no evidence of them in any arguments for inflexible stasis of software defaults so far. . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? After having read several of your previous posts to others on this list, including several containing insults, it seemed to be a fair assumption. I recommend you read for denotative meaning of words rather than for imagined tone in the future. Emails do not generally come with tone of voice. That seems like another implementation detail. I'm not sure how to respond to this. Yes, changes to software do require changing the implementation. When taken in isolation, ignoring everything else I said about implementation details, I suppose it's easy to pretend I said something nonsensical. -- 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] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 03:36:43PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. That is somewhat difficult in my case as I typically run trunk (or very close to it) to use the new/modified features I've been adding. If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. It shouldn't be a surprise, as the migration is currently proposed, unless all those users never upgrade Fossil SCM between now and the some- future-time final change in functionality, thanks to the behavior migration warnings and other indications (including, presumably, a major version number change) that should apply along the way. That is an exceptionally bad assumption. We've had users that did not upgrade over a year. Subsequently, they would sometimes notice a significant behavioral change and report it to us. If rm suddenly started deleting files, I suspect that could induce panic, even if the action could be undone. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. Should all software never ever break any backward compatibility ever, just because something may be automated somewhere by someone who will never pay attention to warnings given by the software itself or will skip many intermediate versions before upgrading to a new, post-change version? Attempting to demonize people for relying on the current behavior seems to be in poor taste. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. Should we always plan changes only for the sake of the most irresponsible users? Being openly hostile to users (i.e. by calling them irresponsible) is also in poor taste. Software that is openly hostile to its user base does not end up being too popular. Finding examples of this is within the industry is left as an exercise for the reader. I'm not calling users in general irresponsible -- only irresponsible users. There *are* irresponsible users in the world, just as there are developmentally disabled people, stupid people, and actually *bad* people. Pretending there aren't such people doesn't change the facts, and we should damned well be able to account for such people when making policy. I'm not even saying that all people who disagree with the need for a change in default `rm` and `mv` behavior are irresponsible. I'm just pointing out that many of the problems raised are non-issues except to irresponsible users, and saying that I think this is a bad prioritization strategy. If to you it's perfectly reasonable to leave it as-is, we aren't even speaking the same language. I'm not sure if this is an attempt to insult me or not; however, I'll just assume that it is not. Not changing something in an incompatible way is always a reasonable choice. I think we'll have to agree to disagree on this. It's not an attempt to insult you. Problem solved. . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? There are several other problems with changing the current behavior: 1. The opposite of add is remove. The add command does not modify the file system. It merely records something to be done for the next commit. Similarly, the current remove command does this as well. The opposite of add could be delete or subtract instead. Notice that the ideas of leaving delete as-is and/or adding a remove alias for it have been raised, and that rm is not exactly the same as remove. I think this point of yours does not exactly hold water. 2. If the mv and rm commands were to be changed to perform some action during commit, that would be very confusing as commit should only modify the repository. On the other hand, if the mv and rm commands were to perform their file system actions prior to commit, would revert need to bring the previous files back to life? That does not make sense. This seems to me like a matter for discussion of implementation, and not of whether the change should be made at all. 3. Related
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 11:06:57AM -0500, daniel gregory wrote: I think we should write a patch… publish is and see how many people actually use the patched version instead of the real version… then we'd have an argument against the conservatives that just don't like change. That's not a bad idea, though I think it should be maintained alongside the unpatched version with equal maintenance and availability for both. Otherwise, it may be that almost nobody uses it. I may not even use it, preferring to script around the undesirable old behavior, if the alternative is to have to patch it myself every time I upgrade or hunt down some non-canonical location for downloads. -- 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] why does `fossil rm' not do the real thing?
these problems do not, in fact, materialize in practice. Your lack of experience with those other systems does not in any way invalidate the question. -- 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] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 05:15:17PM +, Eric wrote: On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin c...@apotheon.net wrote: Why do people feel insulted when it is suggested that they don't know everything? I know what SCM is, you condescending ass. I believe you, but there are some here who don't know, and the message is for everybody. And I did say Well, I had to pick one message to answer. Instead of thinking this bit isn't for me you feel insulted and start being rude. Or rather, continue being rude. I do not understand this behaviour. Your implication that anyone who disagrees with you must not know anything implicitly includes me and everyone else here who disagrees with you. If you are not aware of this fact, I recommend you reread your emails before sending next 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] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 08:26:33PM -0800, Joe Mistachkin wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. Backward compatibility should be broken sometimes. It is a decision that should be undertaken only with great care, but it should sometimes be undertaken. That's an important part of how software improves over time. Whether the current behavior being ideal or not is an entirely different debate. My ideas on this issue are as follows: 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. I disagree. A careful, measured approach to changing default behavior with a clear, unambiguous understanding of when and how things change mitigates the potential for problems. The major version number in semantic versioning practice, in fact, exists specifically for the purpose of indicating that backward compatbility has been broken. Thus, changes to default behavior that break backward compatibility should only be released in major version number releases (and their release candidates, if applicable), additions to the functionality of the software without destructive changes should only be released on major and minor version numbers, and fixes can be released on major, minor, or revision version numbers. This way, when you consider an upgrade, you know what you're getting into just by looking at the number. If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. Apart from the fact that these terms are already used elsewhere with distinctly different meanings (thus duplicating the problem that already exists), it does not solve the problem that already exists. 5. Optionally, add a -f/-filesystem option to the existing mv/rm commands if there is consensus on this point. This new option will cause the exact same behavior as the new commands, including the errors as described above. Honestly, if the repurposing of the rm and mv commands is not to happen (though it should), this is the only suggestion that I think really makes sense for the project. A -f (--force, probably, rather than --filesystem) is better than `relocate` and `obliterate` commands as you have suggested, I think. Of course, the problem of surprising behavior for `rm` and `mv` would still apply in that case. -- 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] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 03:03:26AM -0800, Joe Mistachkin wrote: j. v. d. hoff wrote: POLS comes again to mind. The Principle of Least Surprise is not static. Changing the current behavior would be a huge (and potentially unpleasant) surprise for those who are very actively using Fossil now. It shouldn't be a surprise, as the migration is currently proposed, unless all those users never upgrade Fossil SCM between now and the some- future-time final change in functionality, thanks to the behavior migration warnings and other indications (including, presumably, a major version number change) that should apply along the way. I can tell you that I _was_ surprised (being also a user of svn and hg) when I installed fossil quickly read through the help (ah yes, ci, add, pull, push, rm, mv, stat, log -- default naming scheme for default tasks), Of course, there are much bigger differences between Fossil and those other systems than the semantics of mv and rm. . . . most of which are not *bad* differences like this one. and I do not buy the it'll be really dangerous for so many people prophecy. Obviously, I do buy it. Breaking compatibility is generally bad. It's even worse when other _software_ (i.e. not humans) may depend on the current semantics. The surface area of Fossil is the set of command line options it exposes, since it's a command line tool. In this case, it would not be unlike changing the default behavior of the Unix rm command to implicitly include the -f option. Should all software never ever break any backward compatibility ever, just because something may be automated somewhere by someone who will never pay attention to warnings given by the software itself or will skip many intermediate versions before upgrading to a new, post-change version? Should we always plan changes only for the sake of the most irresponsible users? What are your criteria for allowing something to change? What if all rm did was give you a warning saying You need to issue the command wakka_ wakka_dingbat_eliminate_this_file_from_the_repository because the rm command is only a documentation helper!? Would you say we should never change the behavior of rm and leave everyone stuck with wakka_wakka_ dingbat_eliminate_this_file_from_the_repository forever after to serve the demands of backward compatibility? If your answer is No, of course not! That's just silly! then we've reached a point of agreement where we have established that sometimes breaking backward compatibility is a good idea. All that remains at that point is negotiating the specific cutoff point between good idea and bad idea. If your answer is Yes! on the other hand, I think you and I have absolutely zero common ground for discussion of the matter at all, because wakka_wakka_dingbat_eliminate_this_file_from_the_repository with the described `rm` behavior referring to it is intentionally meant to be regarded as silly beyond reason. If to you it's perfectly reasonable to leave it as-is, we aren't even speaking the same language. -- 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] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 11:08:04PM +, Eric wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. On another note, people are saying things like there is a certain behaviour that is expected without saying why it is expected. The main reasons seem to be that other VCS's do it and that it saves time. The first is irrelevant and the second, in my opinion, a case of people knowing the price of everything and the value of nothing. I think this thread has served to highlight the number of people here who want Fossil to be something other that what it set out to be, and don't actually know what SCM means. It doesn't surprise me that they have caused some over-the-top reactions. I review changes before committing, and I don't just treat a VCS as a backup method. I also believe default behavior should be for an `rm` command to do what it says on the tin, in the most convenient and unsurprising manner possible, because computers and the software running on them are supposed to automate away the mind-numbing drudgery of a rigid series of steps that must be taken regularly to achieve common, conceptually simple tasks -- not add redundancy to the actions that must be taken to maintain workflow. I prefer a `fossil rm` command that removes from disk as well, but I do not fit the description your maliciously insulting description of the evils of such obviously inferior people. . . . and you're an ass. -- 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
