[fossil-users] Ingest CVS repo + cvstrac tickets into fossil?

I've seen some traffic on this list that touches on the issue, but haven't seen anyone offer specific scripts that will let me ingest a CVS repo *plus all my CVSTrac tickets* into fossil. I've successfully used cvs2git to move my repo to a git repo, and successfully imported the git repo into

[fossil-users] admin pages are empty and have bad titles

I've started a fossil repo by importing a git repo to my local laptop, and then cloning the repo over to my target production web server. For testing, I've exposed the fossil server like this: /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080 --baseurl

Re: [fossil-users] admin pages are empty and have bad titles

said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400: /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080 --baseurl http://localhost:10080/ Try removing the --baseurl option. It works for me when I do: fossil server /tmp/test.fossil ssh -L 10080:localhost

Re: [fossil-users] admin pages are empty and have bad titles

to prevent fossil from thinking that it should not authenticate the user. Eric On Wed, Jul 24, 2013 at 10:06 PM, Andy Bradford amb-sendok-137730.cdeapjlkdpclmgfol...@bradfords.org wrote: Thus said Eric Rubin-Smith on Wed, 24 Jul 2013 10:55:24 -0400: Am I doing something wrong with my

[fossil-users] cvs to git to fossil does not preserve user names on check-ins

I exported my CVS repo to git using cvs2git (version 2.4.0-dev), and ingested the resulting git repo into fossil according to the instructions on the fossil web site, using fossil 1.26. My git version is 1.7.7.6. This failed to preserve the original CVS user names. The reason is that git

Re: [fossil-users] Ingest CVS repo + cvstrac tickets into fossil?

On Mon, Jul 22, 2013 at 3:05 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 22, 2013 at 9:04 PM, Richard Hipp d...@sqlite.org wrote: The stumbling block is that the ticket text is Wiki, but the format for Fossil Wiki and CVSTrac Wiki is different, which would require a tricky

[fossil-users] fossil commit is extremely slow

I have a largish repo I ingested from CVS (via git, as I previously described on this list). I'm using fossil 1.26. A tiny commit to a single file takes 63 seconds: [monk:code] $ fossil diff Index: {snip}/test-file == ---

Re: [fossil-users] fossil commit is extremely slow

On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: That is ridiculous. Most commits take less than a second, even on archaic machines, such as my 15-year-old PPC iBook clocked at 400MHz. How many files are in your check-out? [monk:repo.fossil] $ find .|wc -l 8095 What's

Re: [fossil-users] fossil commit is extremely slow

On Sat, Jul 27, 2013 at 4:15 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Jul 27, 2013 at 3:41 PM, Eric Rubin-Smith eas@gmail.comwrote: On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp d...@sqlite.org wrote: What's the total size of all those files (how big is the checkout

Re: [fossil-users] fossil commit is extremely slow

On Sat, Jul 27, 2013 at 4:58 PM, Andy Bradford amb-sendok-1377550706.oeilkncbciakkppah...@bradfords.org wrote: Thus said Eric Rubin-Smith on Sat, 27 Jul 2013 16:31:46 -0400: I tested this basic claim and do not believe it holds: [monk:~] $ head -c $(echo 392*1024*1024|bc) /dev/zero foo

[fossil-users] merging and file names: help text is wrong and conflicts are not reported

From 'fossil help merge': === Only file content is merged. The result continues to use the file and directory names from the current checkout even if those names might have been changed in the branch being merged in. === This struck me as very odd. If the file name only changed on the branch

[fossil-users] fossil silently ignores capitalized ticket table field names

I spent a couple hours hunting for a bug in which fossil does not properly apply changes to my custom fields to the ticket table. The root cause appears to be these lines from cgi.c's add_param_list(): if( fossil_islower(zName[0]) ){ cgi_set_parameter_nocopy(zName, zValue); }

Re: [fossil-users] fossil silently ignores capitalized ticket table field names

... i.e. silently ignore capitalized POST argument names. Is there a reason for that? Yes there is. Thanks Richard. So I was initially planning on doing a brute-force migration to the new ticket table schema with the lowercase letters. But it sounds like that is a pointless exercise,

Re: [fossil-users] commit signing

[507ee45f25] http://localhost:8080/info/507ee45f25 Fix an off-by-one bug in the network protocol handler so that it can accept a zero-length file. (*PGP SIGNED*) (user: drhhttp://localhost:8080/timeline?u=drhc=2007-08-25+12%3A31%3A55nd, tags:

Re: [fossil-users] commit signing

If you guys are going to get into this more deeply, you should probably also consider revocation issues. That is, what happens when it is discovered that a contributor's private key has been compromised? The discovery date of the compromise is obviously = the compromise date. As such, some set

Re: [fossil-users] Ticket system

On Thu, Aug 29, 2013 at 6:02 PM, Jan Jurak yan.ju...@gmail.com wrote: Dear developers, First thank you for nice piece of software. I am using fossil for some of my projects and some users wants more featured ticket system. For example spent time for solving the issue. What is your opinion on

Re: [fossil-users] Version 1.28 release?

I have a request. Can you guys do the official builds SSL-enabled? On Sat, Jan 11, 2014 at 2:22 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/11 Richard Hipp d...@sqlite.org: I don't think this should hinder the release. That's great news. So the valgrind error in the /tar page and

[fossil-users] autosync from GUI

Is it reasonable to ask that the 'autosync' setting cause artifacts created from the GUI to also be autosynced? I know this would likely increase the latency of the GUI, and would possibly create a series of error cases and/or user interactions that do not need to be handled in the GUI today.

Re: [fossil-users] autosync from GUI

Stephan Beal wrote: I know this would likely increase the latency of the GUI, and would possibly create a series of error cases and/or user interactions that do not need to be handled in the GUI today. But I believe that today's behavior nevertheless violates the principle of least

Re: [fossil-users] Sometimes fossil doesn't sync properly

I believe I have seen this issue. It's been a while, but here is the scenario as far as I can recollect: 1. Assume there are three repo copies in a master/client topology: M, C1, and C2. M is the master, and C1/C2 are clones of the master (meaning that C1 and C2 don't know about each

Re: [fossil-users] Sometimes fossil doesn't sync properly

It may be that you need to replace the one giant file in the below scenario with a great many files that as a whole take up a lot of bytes. I don't remember. Sorry. :-/ On Thu, Jun 12, 2014 at 2:46 PM, Eric Rubin-Smith eas@gmail.com wrote: I believe I have seen this issue. It's been

Re: [fossil-users] fossil CLI tricks: interrupting a commit message

This thread is hilarious. I thought I was pretty old-school -- I use vi, xterm, fvwm2, and other tools written by my forebears around the time when I was born. I get made fun of by people twice my age for my dev toolkit. But even *I* will have two terminals up concurrently -- so that I can

Re: [fossil-users] committing to a *new* branch from a closed branch not currently possible?

Stephan Beal wrote: On Fri, Jul 18, 2014 at 6:06 PM, Matt Welland estifo...@gmail.com wrote: It seems it is not possible to commit to a new branch from a closed branch. this is version 1.28. I think this should be allowed. Closing a branch only implies to me that no more commits are

Re: [fossil-users] committing to a *new* branch from a closed branch not currently possible?

Matt Welland wrote: From http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki: == Closed Leaf A closed leaf is any leaf with the closed tag. These leaves are intended to never be extended with descendants and hence are omitted from lists of leaves in the

Re: [fossil-users] committing to a *new* branch from a closed branch not currently possible?

Matt Welland wrote: The scenario I'd like to see supported is roughly as follows: Work on a release is done. The release manager closes the branch so no one can accidentally merge or commit to it. A bug fix is needed. The developer branches off the closed node and fixes the bug

Re: [fossil-users] slow commit

Gour wrote: Stephan Beal sgb...@googlemail.com writes: i don't have any more ideas off-hand, but i've never worked with repos having anywhere near that many files. Maybe a list-member who has can suggest something. Maybe it's something as simple as changing the sqlite3 write mode (and

[fossil-users] fossil vs git-based arrangements. code review and ticket export

I'm starting a company with some folks. Their notion of the default choice for SCM is git + JIRA for bug tracking + some other tool we'd pick for code review. This is probably quite common. Since the answers to my questions will probably be interesting to a relatively wide audience, I hope the

Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export

Richard Hipp wrote: Is there a better story for moving between any two bug tracking systems? Do there exist any two bug tracking systems in the world were you can move from one to the other without having to write some scripts to transform the data? I can't tell whether you're asking

Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export

More seriously, you're comparing a small project like Fossil's with the capabilities of behemoths like Microsoft. No, I'm really not. drh was making a claim that users will ALWAYS have to convert between two database schemas when exporting tickets from one system to another. He was making a

Re: [fossil-users] How to export ala CVS?

Andy Bradford wrote: Does Fossil have an option that exports a particular revision of the repository similar to how CVS export works? CVS export will export either HEAD or an explicit revision to a named directory without all the CVS control directories/files in the export. As

[fossil-users] crash while running 'fossil pull' on Linux

I configured fossil to use openssl (for https) and built it for Linux (kernel 3.11.0-12-generic, Ubuntu 13.10). Fossil crashes during the 'pull' portion of a 'fossil update' or just while running 'fossil pull'. The pull implies the transfer of a few large artifacts (~60MB range) as well as lots

Re: [fossil-users] crash while running 'fossil pull' on Linux

Stephan Beal wrote: On Tue, Aug 19, 2014 at 7:31 PM, Warren Young war...@etr-usa.com wrote: On 8/18/2014 19:39, Eric Rubin-Smith wrote: warning: Can't read pathname for load map: Input/output error. That looks like a corrupted stack to me. Try running it under Valgrind

[fossil-users] symlinks

Any plan to support symlinks any time soon? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks

On Thu, Aug 28, 2014 at 10:55 AM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith eas@gmail.com wrote: Any plan to support symlinks any time soon? ??? [stephan@host:~]$ f help set | grep -C3 sym access-log If enabled, record

[fossil-users] edits to ticket table not synchronized with 'fossil config pull all'

In one of my fossil repos, I edited the tickets table by adding a column. I wanted to pull the new column definition into a repo clone, so I said fossil config pull all from the other repo, to no avail. New reports, the New Ticket and Edit Ticket pages and so on were properly synchronized,

Re: [fossil-users] edits to ticket table not synchronized with 'fossil config pull all'

Andreas Kupries wrote: You have to run fossil rebuild on _all_ repositories with the new definition. This rebuilds the derived tables (TICKET, TICKETCHNG) from the actual tickets, and ensures that they actually have the new column you defined. Works like a charm -- thank you sir!

[fossil-users] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

], gimme) === -- Eric Rubin-Smith ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] late-night Fossil hacks for competition with Git: arranging an active feed of commits and tickets to a remote HTTP API

Ron W wrote: This enhancement to Fossil will certainly make integration with other tools easier, not just Slack I was thinking of an example: git. Right now there's a bulk import from git, and a bulk export to git. The present feature might be used along with git's hooks features to

[fossil-users] fossil - JIRA hooks

Does anyone have any experience with hooking up fossil to JIRA? Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil - JIRA hooks

Ron W wrote: Does anyone have any experience with hooking up fossil to JIRA? Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? I guess I meant the former, though the latter is

Re: [fossil-users] fossil - JIRA hooks

Stephan Beal wrote: That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1

Re: [fossil-users] fossil - JIRA hooks

As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? Sorry to self-reply. I meant for the sense of this question to be constrained specifically to the git-to-JIRA hooks or JIRA itself -- not to git as a stand-alone

Re: [fossil-users] fossil - JIRA hooks

Stephan Beal wrote: In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are

Re: [fossil-users] Getting configure to find openssl on FreeBSD

org.fossil-scm.fossil-us...@io7m.com wrote: 'Lo. The fossil build scripts seem to be unable to find openssl on FreeBSD 9.2. It has a choice of the version included with the base system (in /usr) or the version available from FreeBSD ports (/usr/local), but it can't seem to find either of

[fossil-users] minor bug on export to git

When exporting to git, the check-in comments that are exported are the original comments. If you had subsequently edited the comments, then those edits are not retained during the export. Eric ___ fossil-users mailing list

[fossil-users] push fails with complaint about manifest syntax error

I haven't changed much recently about my repository topology. One central master repo that I push to from my dev repo. No one else is doing any pushing. The master repo has hooks set up for publishing my commits etc to a remote HTTP REST API. The only change I made recently is to open up my

Re: [fossil-users] push fails with complaint about manifest syntax error

Stephan Beal wrote: According my debugger, that uuid is 41 bytes long, including a carriage-return character. How on earth that happend is a mystery to me, as fossil does not use \r characters anywhere unless it's prescribed by a standard (e.g. HTTP headers). The C-card also contains a

Re: [fossil-users] push fails with complaint about manifest syntax error

Richard Hipp wrote: Are you sure that is the manifest that is causing the problem? Perhaps we should enhance the error message to include the UUID of the problem manifest as part of the error message? In case you find it useful for your debugging, I have continued plodding along with my

Re: [fossil-users] push fails with complaint about manifest syntax error

Stephan Beal wrote: Working on a patch now. Sorry, I'm realizing that the Fossil version I mentioned (1.29) is tainted with my own private changes to the C code (to get my TH1 hooks working). I submitted them to this list, and Joe Mistachkin accepted them -- but with significant changes. It

Re: [fossil-users] push fails with complaint about manifest syntax error

Richard Hipp wrote: Can you try compiling the tip of the better-error-msgs branch and put that on your server, then let us know what the new error message is? Our emails crossed paths. I'll do as you suggest and let you know what happens. -- Eric A. Rubin-Smith Aterlo Networks, Inc.

Re: [fossil-users] push fails with complaint about manifest syntax error

Richard Hipp wrote: Can you try compiling the tip of the better-error-msgs branch and put that on your server, then let us know what the new error message is? Here we go: $ fossil push Push to https://eas@snip:10444/ Round-trips: 1 Artifacts sent: 2 received: 0 Error: push script failed:

Re: [fossil-users] push fails with complaint about manifest syntax error

Eric Rubin-Smith wrote: $ fossil push Push to https://eas@snip:10444/ Round-trips: 1 Artifacts sent: 2 received: 0 Error: push script failed: syntax error in manifest [449bc674c3fc9c036db0d4dc71281b7cb900fe7d] Round-trips: 1 Artifacts sent: 2 received: 0 Push finished with 818173

Re: [fossil-users] push fails with complaint about manifest syntax error

Stephan Beal wrote: You mention custom changes with regards to push scripts, which make me curious about that error message: i can find push script failed nowhere in fossil. Where is it coming from (if you know)? The strings are escaped :) eric@dev:~/Fossil-5ff4e33617/src$ grep -r 'push\\s'

Re: [fossil-users] push fails with complaint about manifest syntax error

Stephan Beal wrote: FYI: i committed one on top of that. The advantage is that it's centralized, the disadvantage is that it hashes every manifest before parsing (to get the UUID, since parsing modifies it). Might be considered too expensive, considering how rare broken manifests are.

Re: [fossil-users] push fails with complaint about manifest syntax error

Stephan Beal wrote: We'd be interested in hearing back if you discover how an error on your end (if indeed it is) is confusing fossil into trying to read non-manifest files as manifests. Actually, your question sort of confuses me. From my (very tenuous) understanding of the code, it

[fossil-users] proposed patch: symlinks appear as regular files even when allow-symlinks is on

Even when I have the versionable 'allow-symlinks' setting on, 'fossil open' initially creates symlinks as regular files (as if .fossil-settings/allow-symlinks did not exist or were set to 'off'). I have to first delete the symlink files and then run 'fossil update' in order for the setting to

Re: [fossil-users] Larger diff possible?

Jungle Boogie wrote: It absolutely is a side-by-side. I'm asking if its possible to maximize or display the diffs in a larger format with larger font. Try holding down the Control key and then hitting the Equals key = on your keyboard a few times. In most browers these days, that zooms in

Re: [fossil-users] proposed patch: symlinks appear as regular files even when allow-symlinks is on

Richard Hipp wrote: sqlite3_snprintf() is guaranteed to be available. Note, though, that the first two parameters are reversed. :-\ Well, I only really want to copy up to 3 bytes, so we can keep it simple, stupid and just not make a function call. The revised patch is below. But in

Re: [fossil-users] proposed patch: symlinks appear as regular files even when allow-symlinks is on

Another iteration. We need to add an extra byte in case the true value is the string true. I've re-expressed the loop as a 'for' loop while I was at it. Sorry for the spam. Again, please treat the below with caution until I have (or someone else has) a chance to exercise it better. Index:

Re: [fossil-users] How to fix parallel timeline

Are you sure your students didn't shun something or try to use reconstruct? What would happen if the student tried to push a repo that they had created with 'fossil init' to the central clone? ___ fossil-users mailing list

Re: [fossil-users] How to fix parallel timeline

... unless the students used raw SQL to hack there project-id to make it match the repository into which they were pushing. But I'm thinking that is not what happened here. Little anecdote. When I was a student we were using CVS for our big project. One teammate couldn't understand why his

Re: [fossil-users] Justification for two-step mv and rm

I fwiw have always found Fossil's mv and rm semantics odd. The following semantics are basically what I expected when I first started using Fossil, but extended to preserve backward compatibility. They basically do what the user intended in all cases, do they not? * fossil rm FILE: * If

Re: [fossil-users] please compile official fossil builds with https support

On Wed, Jun 10, 2015 at 3:46 PM, Richard Hipp d...@sqlite.org wrote: On 6/10/15, Eric Rubin-Smith eas@gmail.com wrote: On Wed, Jun 10, 2015 at 3:30 PM, Richard Hipp d...@sqlite.org wrote: On 6/10/15, Eric Rubin-Smith eas@gmail.com wrote: If you are worried that some people

[fossil-users] please compile official fossil builds with https support

$ fossil pull Pull from https://eas@.../ HTTPS: Fossil has been compiled without SSL support Pull done, sent: 0 received: 0 ip: $ This burdens adoption, since now I have to build my own fossil and distribute that to people on my team internally, rather than just pointing them at the web site.

Re: [fossil-users] please compile official fossil builds with https support

On Wed, Jun 10, 2015 at 8:50 PM, Eric Rubin-Smith eas@gmail.com wrote: Eric: Can you discover what apt-get is needed in order to statically link libssl using -m32? Perhaps this? # apt-get install libssl-dev:i386 Warning: I just got that command line from google and verified apt

Re: [fossil-users] please compile official fossil builds with https support

Eric: Can you discover what apt-get is needed in order to statically link libssl using -m32? Perhaps this? # apt-get install libssl-dev:i386 Warning: I just got that command line from google and verified apt-get accepted it -- didn't actually try to link against the libs in that package.

Re: [fossil-users] please compile official fossil builds with https support

On Wed, Jun 10, 2015 at 9:56 PM, Eric Rubin-Smith eas@gmail.com wrote: -LIB = -m32 -L1/lib -lssl -lcrypto -lz -ldl -lm +LIB = -m32 -L1/lib /usr/lib/i386-linux-gnu/libssl.a /usr/lib/i386-linux-gnu/libcrypto.a -lz -ldl -lm I suppose this is sexier: LIB = -m32 -L1/lib -Wl,-static

[fossil-users] minor: broken hyperlink in fossil web site

From the download page for v1.33, Improved ability to customize the timelime graph https://www.fossil-scm.org/customgraph.md is a broken link. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org

Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal <sgb...@googlemail.com> wrote: > > On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith <eas@gmail.com> > wrote: > >> the user when trying to move a tarball from one OS to another. In other >> words, I b

Re: [fossil-users] symlinks (was Re: xkcd on git)

> > > Just to clarify, what are the behavioral changes needed on the Unix side to > make > things work seamlessly? > (1) Default allow-symlinks to true (2) Fix bug in which the allow-symlinks setting is not honored while opening a repository (requires manual clean-up of symlinks after opening a

Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 4:51 PM, Joe Mistachkin <sql...@mistachkin.com> wrote: > > Eric Rubin-Smith wrote: > > > > (1) Default allow-symlinks to true > > (2) Fix bug in which the allow-symlinks setting is not honored while > > opening a repository > > >

Re: [fossil-users] Fossil does not generate https link prefix

On Thu, Nov 5, 2015 at 6:53 AM, Richard Hipp wrote: > On 11/4/15, Eduard wrote: > > Hi Taras, > > > > I've had a very similar problem. I fixed it by setting the "HTTPS" > > environment variable (for CGI execution) to "on" when the request comes >

Re: [fossil-users] symlinks (was Re: xkcd on git)

On Thu, Nov 5, 2015 at 1:56 AM, Stephan Beal wrote: > > Thanks to Joe for stepping in to stop the bikeshedding :). > Yeah. In that spirit, I will abstain from addressing your other points from this morning, since I think most of the useful arguments are already on the

Re: [fossil-users] symlinks (was Re: xkcd on git)

> > This issue was more subtle than it originally appeared. I think the > current > trunk > changes should make it work right for both versioned and non-versioned > allow-symlinks > settings. Thanks so much for looking at that. I was trying to get started writing some unit test cases around

Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 2:44 PM, Joe Mistachkin <sql...@mistachkin.com> wrote: > > Eric Rubin-Smith wrote: > > > > (2) Fix bug in which the allow-symlinks setting is not honored while > > opening a repository > > > > Did the following changes (a while

[fossil-users] symlinks (was Re: xkcd on git)

> My problem is not the decision itself, but that, in terms of how fossil >>> should behave, it's a philosophical question. Those have no right/wrong >>> answer, and i dislike seeing software pretend to know the answer to such >>> questions. >>> >> >> Isn't that essentially confirming my point?

[fossil-users] xkcd on git

I suspect Fossil folks will appreciate this :-) http://xkcd.com/1597/ Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

> - Symlinks. Now we're getting into file system specifics. Some users > may want to track them because they find them useful. What about users > that find FIFOs or block devices or character device useful? Should > fossil attempt to save enough information to recreate them? > Support for FIFOs

[fossil-users] merge after cherrypick plus edit does not identify GCA as I would like

See the transcript below for gory details. The summary is: 1. create a new file on trunk and check it in. 2. edit the file and check in on a branch (let's call it "beta") 3. trunk decides it wants that particular change set from step (2), so cherrypick it (assume in this example that other stuff

Re: [fossil-users] merge after cherrypick plus edit does not identify GCA as I would like

> The merge algorithm does *not* consider cherry-picks. It looks for > the most recent common ancestor without taking cherry-picks into > account. Another popular version control tool whose name I won't mention (hint: rhymes with "zit") behaves identically to fossil in this scenario. Is there

Re: [fossil-users] merge after cherrypick plus edit does not identify GCA as I would like

> Merge is done by a classic 3-way diff. It looks at all the changes > that occurred on the path from A to B and applies those same changes > to C. (A in this case would be the most recent common ancestor of B > and C). > > How would cherry-picks factor into this? > Sorry, maybe I'm confused.

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

On Wed, Dec 16, 2015 at 11:16 AM, Richard Hipp wrote: > Based on comments on HN and on this mailing list, I have attempted to > rewrite the fossil-v-git.wiki document > (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to > better summarize the differences

Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

> > > >> Would be nice if there was a "fossil ticket export" command that would > > >> produce a "proper" CSV file. {snip} > > > A problem with CSV is that there really isn't a clear definition of it > at > > > its edge cases other than testing what Excel will import correctly. > > > > Which is a

[fossil-users] allow downloading wiki page attachments for users without Read permission

A user with the following permission flags: bcfhjkmnprtw for a site in which the virtual users Reader, Developer, Anonymous and Nobody have no default privileges, cannot download an attachment directly from a wiki page attachments list. The list points to URIs such as this one:

Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

> On May 27, 2016, at 12:26, Andy Gibbs wrote: > > Hi, > > I've just had a very, very odd experience with fossil. I'm running version > 1.34. > > Let me first explain what I have done. > > I cloned a respository off our server. I then went into the clone's web UI

Re: [fossil-users] Semi-annual drumming-up-of-support for libfossil

On Thu, Jan 21, 2016 at 11:36 AM, Stephan Beal wrote: > On Thu, Jan 21, 2016 at 5:27 PM, Christopher M. Fuhrman < > cfuhr...@pobox.com> wrote: > >> Is your Caps-Lock key to the left of the 'A' key on your keyboard? If so, >> I've had good luck swapping the Caps-Lock key

Re: [fossil-users] Conversation with a CM guy

> > > So far, none of the IDEs I've used seem to support VCS merges from within > the IDE. I've always had to go to the VCS itself (or, when using Hg or SVN > on Windows, TortoiseHg or TortoiseSVN), so lack of merging in libfossil > might not be a big issue for creating Fossil plug-ins for IDEs. >

Re: [fossil-users] Conversation with a CM guy

> > employability. It takes less than a day to pick up git if you're used to fossil. So I don't really think it makes a huge difference as to future employability unless the hiring manager is looking for the wrong things. I grant that most hiring managers *do* look for the wrong things, but

Re: [fossil-users] Purging data from Fossil

> > > (A) Suggest a better name than "fossil trim" > > (B) Define the syntax of ARGS. > > (C) Define a safety mechanism that allows content to be restored if > it is accidentally trimmed when there are no other repos available > with which to sink. Perhaps the trimmed content gets written into