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

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

[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 http://localhost:1

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

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

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

esolution system does not squash the two slashes -- there's a paged named "page_name" but none named "/page_name". Am I doing something wrong with my configs, or is a code change warranted? On Tue, Jul 23, 2013 at 10:30 PM, Eric Rubin-Smith wrote: > Yes, that works fo

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

n Wed, Jul 24, 2013 at 11:55 AM, Mark Janssen wrote: > What happens if you set base_url without trailing slash? e.g. " > https://foobar.com:10443"; > > > On Wed, Jul 24, 2013 at 4:55 PM, Eric Rubin-Smith wrote: > >> I think the point here is that with a baseurl of

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

way, the "--https" argument there is required 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, 2

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

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

On Mon, Jul 22, 2013 at 3:05 PM, Stephan Beal wrote: > On Mon, Jul 22, 2013 at 9:04 PM, Richard Hipp 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 >> translator. >> > > But the ticket

[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 == --- {snip}/tes

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

On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp 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 the total

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

On Sat, Jul 27, 2013 at 4:15 PM, Richard Hipp wrote: > > > On Sat, Jul 27, 2013 at 3:41 PM, Eric Rubin-Smith wrote: > >> On Sat, Jul 27, 2013 at 3:23 PM, Richard Hipp 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

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

[fossil-users] rebasing dev branches

I was poking around at the fossil dev timeline and noticed that rebases appear to be direct children of the trunk stream, rather than the dev stream. That is, the fossil devs' work-flow seems to be: * dev says: "let's make a new feature against the trunk". * fossil update trunk * * fossil commit

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

Re: [fossil-users] commit signing

> > [507ee45f25] Fix an off-by-one > bug in the network protocol handler so that it can accept a zero-length > file. (*PGP SIGNED*) (user: > drh, > tags: > trunk

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 o

Re: [fossil-users] Ticket system

On Thu, Aug 29, 2013 at 6:02 PM, Jan Jurak 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 > that. I am t

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 wrote: > 2014/1/11 Richard Hipp : > > I don't think this should hinder the release. > > That's great news. So the valgrind error in the /tar page and > the two failing test-cases (wh

[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. But

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

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 wrote: > I believe I have seen this is

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 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 to be ma

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 leave

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

Re: [fossil-users] slow commit

Gour wrote: > Stephan Beal 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 maybe it's n

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

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 aski

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

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

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

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

Stephan Beal wrote: > On Tue, Aug 19, 2014 at 7:31 PM, Warren Young 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 corrup

[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 wrote: > > On Thu, Aug 28, 2014 at 4:51 PM, Eric Rubin-Smith > wrote: > >> Any plan to support symlinks any time soon? >> >> > ??? > > [stephan@host:~]$ f help set | grep -C3 sym >access-log If e

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

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

a file transmitted from the server. */ if( blob_eq(&xfer.aToken[0],"file") ){ -xfer_accept_file(&xfer, (syncFlags & SYNC_CLONE)!=0); +xfer_accept_file(&xfer, (syncFlags & SYNC_CLONE)!=0, 0, 0); nArtifactRcvd++; }else

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 pe

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

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 en

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 ar

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

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

org.fossil-scm.fossil-us...@io7m.com wrote: > Think that may be partly wrong, as that'd mean that if I specified /usr, > then the following would have to exist: > > /usr/openssl/ssl.h Yeah, my mistake. The configurator does this (from auto.def): set cflags "-I$dir/include" set ldflags "-

[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@lists.fossil-scm.

[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: > > and then the manifest should be dumped to "manifest.uuid". Please post the > > contents of that file for a checkin which fails this way, and i think that > > will show us what's wrong. Keep in mind that this 'master' repo doesn't have any sandboxes open against it. It jus

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

Stephan Beal wrote: > > and then the manifest should be dumped to "manifest.uuid". Please post the > > contents of that file for a checkin which fails this way, and i think that > > will show us what's wrong. And, just to add some fun, I just got a different error message while trying to run 'syn

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

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 no

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

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@:10444/ Round-trips: 1 Artifacts sent: 2 received: 0 Error: push script failed: sy

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

Eric Rubin-Smith wrote: > $ fossil push > Push to https://eas@: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

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\

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 tak

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 i

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 fu

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

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 FILE

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 fossil-users@lists.fo

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

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

>From the download page for v1.33, "Improved ability to customize the timelime graph " is a broken link. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/ma

[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 3:30 PM, Richard Hipp wrote: > On 6/10/15, Eric Rubin-Smith wrote: > > > > If you are worried that some people don't want the bloat of openssl in > > their base fossil, perhaps provide both options on the site? > > > > It's

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

On Wed, Jun 10, 2015 at 3:46 PM, Richard Hipp wrote: > On 6/10/15, Eric Rubin-Smith wrote: > > On Wed, Jun 10, 2015 at 3:30 PM, Richard Hipp wrote: > > > >> On 6/10/15, Eric Rubin-Smith wrote: > >> > > >> > If you are worried that some people

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 8:50 PM, Eric Rubin-Smith 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 comman

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

On Wed, Jun 10, 2015 at 9:56 PM, Eric Rubin-Smith 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 -l

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

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

[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

[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? Fos

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

On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal wrote: > > On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith > wrote: > >> the user when trying to move a tarball from one OS to another. In other >> words, I believe that you perceive a dichotomy that is false (between

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 an

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

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

On Tue, Nov 3, 2015 at 2:44 PM, Joe Mistachkin 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 back) not address this? > >

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

On Tue, Nov 3, 2015 at 4:51 PM, Joe Mistachkin 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 > > > > Please try the latest

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 thi

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 > > in through https, i.e. > > > > > > SetEnv HT

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 table. Instead I'll just h

[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: https://www.exam

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 between the two produc

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

On Wed, Dec 16, 2015 at 7:15 PM, Warren Young wrote: > On Dec 16, 2015, at 10:52 AM, Eric Rubin-Smith wrote: > > > > Providing an outbound export interface to at least one such tool > > Which one? I count over 40 in the Wikipedia list: > > https://en.wikipedia.o

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 s

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 with the Control key so m

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 le

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] 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 > and disabled the auto-