Re: [fossil-users] default web config
fossil config [import|export] skin -R repo.fossil There are lots more areas (skin, above) and actions. 'fossil help configuration' for the rest On Sun, Jan 19, 2014 at 11:59 AM, 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. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
status stash merge 'branch ls' undo/revert I prefer status to changes because it shows me where I'm coming from (current checkout and branch). I use it by habit after every phone call, coffee break, and misc interruption, so I'd bet probably more than any other command. On Monday, September 2, 2013, Joerg Sonnenberger wrote: On Mon, Sep 02, 2013 at 06:36:42PM +0200, Stephan Beal wrote: i'm looking to prioritize some work on libfossil and i got the idea to try to find out which commands people use most often, and use that to help me prioritize. Recursive add and revert would be the biggest item :) Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org javascript:; http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
For some irrational reason I avoid addremove as well. I find myself piping
fossil changes through grep and awk and then xargs-ing back to fossil rm or
add whenever it comes up - and I *know* that addremove will do the same
thing.
I just can't bring myself to use it :)
On Monday, September 2, 2013, Stephan Beal wrote:
On Mon, Sep 2, 2013 at 8:41 PM, Martin S. Weber
ephae...@gmx.netjavascript:_e({}, 'cvml', 'ephae...@gmx.net');
wrote:
I find it easy to bring my checkout to the state I want the DB to reflect
and then just go ahead and do so in a single swoop. Getting (all) files
in place and teaching fossil about it is one of my use cases, if you
will.
i can see that being useful for an initial setup, but how often do you set
up new repos? Surely you do other things more often than addremove?
What i tend to do with a new tree is kind of sloppy:
f add .
fst
and then go 'f rm' any which i don't want.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil built-in CGI: it uses `SCRIPT_NAME` instead of `REQUEST_URI`?
On Tue, Aug 27, 2013 at 12:26 PM, Yannick yannick_duch...@yahoo.fr wrote: snip as I like to hide CGI stuffs from the visitor's eyes See also Stephen's response here for another way to do this. http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13040.html hth, Themba ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bikeshedding opportunity: back to the topic of libfossil's name
On Thu, Aug 22, 2013 at 10:30 AM, Chad Perrin c...@apotheon.net wrote: On Thu, Aug 22, 2013 at 10:45:08AM +0200, Stephan Beal wrote: On Thu, Aug 22, 2013 at 4:34 AM, Chad Perrin c...@apotheon.net wrote: mirror should be set up on GitHub to boost its search engine ranking a little bit (with a prominent mention of its canonical version control repository being elsewhere using Fossil itself, of course). While OMG! lol. It never occurred to me to do such a thing, but you're right, it would probably be a good idea. I'd like to be kept abreast of how you accomplish that in an automated manner. I too would like to do that with some projects of mine, but it's low enough on the priority list for my own stuff right now that I won't get to it for a while. If you end up doing the hard work of figuring out the best way to do it sooner than I'd get around to even starting, it could save me a lot of effort. Did you say best way? I can't really help you there, but I do run the following script from time to time to keep 20+ fossil repos synced to private bitbucket repos. Github vs bitbucket should just be a matter of what the prefix portion of the remote path is -- it's all just git of course. https://gist.github.com/tifletcher/5399728 Caveats: - Everything is hard coded and is really just a rough draft / not intended for public consumption. - I'm calling 'tree' at the end because it helps me visualize / confirm what I just did. Please delete that line if 'which tree' returns nothing on your system. - You have to clean up the 'export' directory by hand at the moment (I don't personally like seeing rm -r in a script ... especially one that I run infrequently) On the other hand it has been working quite well for me with multiple pushes looking as expected on the remote for a while, so maybe it can be a starting point for you? And if you fix it please do fork and republish and let me know :) Best Regards, Themba ___ 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] strange `fossil diff ' behaviour
On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland estifo...@gmail.com wrote: Regarding stable numbered tags. How about a script or added feature that scans the timeline and tags every node in a systematic way similar to what people might expect from Subversion or similar tools? v1.1 - v1.2 - v1.3 \.- v1.1.1 I think this is a really interesting idea. If the script worked incrementally and was run centrally or by only one maintainer then the tags would be stable. Perhaps a clean up mode would add/remove tags if there were collisions due to two parallel runs of the script. What if a repo had a blessed as the single source of revision numbers setting. That fossil, and only that fossil, would then add the system tag 'rev' or 'revnum' or something with the next available integer as the data to any new artifacts it sees that do not have a 'rev' tag, and the friendly revision numbers could flow out from that source of truth as a natural part of the syncing process. This could be conceptually just like the bgcolor tag -- I'm not sure what fossil does if there's a color conflict between repos but I'd bet the same logic would work here. And there really shouldn't be a need for conflict resolution outside of each repo protecting itself -- having two single sources of truth in the same graph is pretty much undefined by definition, right? I guess it would make sense for a blessed fossil to refuse to sync with another blessed fossil though :) For very little overhead (I assume having lots of tags is a negligible burden on fossil) those folks wanting an easy to use and sequential way to identify nodes would be made mostly happy. The more I think about it the more I like this. Even though I'm very happy with the hex node keys I'd like to be able to think about commits in terms of human friendly names that convey temporal relationship and I could live with the risk of mutability of tags. The win is apparent, I think. The disadvantages that I can see up front are; * Philosophically, the repos in a network are no longer all equal. Suspect this could be a bigger issue for some than for others. * The revisions are not strictly temporally ordered -- if a developer goes of to the Bahamas for two weeks and syncs when she gets home then all of her commits will be numbered when the blessed repo receives them. Strikes me as a good tradeoff for immutable revision numbers though -- and with autosync mode this should be a non-issue for most. * No revision number until you sync with the revision numbers source. Yuk, but I can't see what could possibly be done about this -- and I can imagine this as a huge source of list noise. * I have no idea how you would set up a topology other than a plain star / tree with this mechanism. What would happen with the canonical fossil-scm topology with three in the middle, for example? Someone commits to the wrong repo and all of a sudden it's sorry, no version number for you until the next round of synchronization in an hour? Anyways, I'm really just thinking out loud here. Themba ___ 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
Ooh, I love bikeshedding. What about libfree as a portmanteau of lib, fossil, and three? I guess that crosses the line into humor a bit. More seriously though, fossil(3) is my favorite, but it does make it sound like it's an official part of the fossil project and actually implies, at least to me, that fossil(1) is built on top of it. Whether or not that implication is common and / or appropriate I'll leave to you to negotiate with Richard. On Wed, Aug 21, 2013 at 10:11 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, The current list of upvoted names (no, Brad, urvogel's not one of them ;) for the on-going/up-coming library API includes (in my personal order of preference, but i'm not emotionally attached to these): - libfossil-scm and fossil(3) - libfossil - liblissof (fossil, backwards, because that's what this approach to Fossil is) i think that was about it? i _really_ liked the idea of the name (i've forgotten) which was a reference to a famously fake fossil, but i have been warned by one wiser than myself to avoid attempts at humorous names (his example being libiberty) and i tend to agree with him that such attempts eventually backfire in some way, shape, or form. (Side-note for history buffs: go look up the history of the mail reader Alpine's name, going all the way back to the first mail program (mail).) i'm still completely open for names but i keep finding myself writing libfossil and fossil(3) everywhere (i'm a doc fanatic), and would like to settle on one or the other relatively soon. Likewise, but of interest only to C coders, the main headers currently look like: #include fossil-scm/fossil.h // public API #include fossil-scm/fsl_internal.h // internal/pseudo-private API, will rename to fossil-internal.h eventually, for consistency If you C programmers feel strongly for some other convention, please speak up. You can peak at the code-related conventions here: http://fossil.wanderinghorse.net/repos/f2/doxygen/ (see the bottom half of that first page) and i am not emotionally attached to many of those, so feel free to suggest, e.g. better API name prefixes. The vast majority of things like that are trivial to refactor with a few lines of perl or sed (my main argument for keeping the repo db outside of the checkout dir, btw ;). Your opinions on the topic are much appreciated! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SSH implementation.
On Tue, Aug 13, 2013 at 10:12 AM, David Mason dma...@ryerson.ca wrote: All I want is for my users to say: fossil clone ssh://remote/proj.fossil clone.fossil or similar (without identifying any fossil user or password in the command - or prompted), and have ssh fire off a remote fossil based on the ssh.pub file they've given me and connect them as a fossil user name that I've chosen for each of them. The following works for me with stock fossil at least as far back as 1.25: - All of my repos are on a simple ssh-capable shared host under the account 'fossil'. Anyone with a public key in the server's authorized-keys file could ssh to that server and do whatever they wanted. - In each user's ~/.ssh/config (just for convenience): Host vc HostName vc.example.com User fossil - now each developer does the following: $ fossil clone ssh://vc/repos/test2.fossil test2.fossil $ fossil user add the name you want them to use $ fossil user default the name again I think this pretty much covers your requirements, though unlike Andy's solution it does assume a level of trust and the user stuff is enforced by policy rather than by the software. I'm pretty sure if you have added the users to the upstream repo you can pull the users down instead of adding them to each cloned repo -- but I can't for the life of me remember how. You would still have to issue the 'fossil user default whatever' command so that local checkins come from the correct user. This is kind of a new workflow for me, so I haven't really explored the edge cases yet. At the very least any local-repo changes show up after a sync with the correct username on the remote, which is the basic level of functionality that I was looking for. ___ 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] Status of the hidden tag
Hi all, My apologies for being noisy with this. I think it was unclear what I was specifically asking. I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: - Can I add the hidden tag to a check in? If not, what can I add it to? - Should I add it from the web interface or do I need to add it from the cli with the --raw option? - Does adding it do anything at this time? - If not, is this still a planned feature or should I forget I read about it? And maybe should the wording on /shun be updated? Thanks in advance, Themba On Thu, Jul 25, 2013 at 11:03 AM, Themba Fletcher themba.fletc...@gmail.com wrote: From fossil's /shun page: Do not shun artifacts merely to remove them from sight - set the hidden tag on such artifacts instead. The only other reference I could find while searching this list was a note from drh (circa 2009 or so?) noting that it had not been implemented yet. Is this still the case? I just tried, via the web interface, adding a hidden tag to a checkin on one of my mistake branches and the timeline still showed the item. Perhaps there's a setting I've missed -- or perhaps something else? $ fossil version This is fossil version 1.26 [674a24a360] 2013-07-20 16:43:45 UTC Best Regards, Themba ___ 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 1:43 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 9, 2013 at 4:32 PM, Themba Fletcher themba.fletc...@gmail.com wrote: Hi all, My apologies for being noisy with this. I think it was unclear what I was specifically asking. I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: - Can I add the hidden tag to a check in? If not, what can I add it to? - Should I add it from the web interface or do I need to add it from the cli with the --raw option? - Does adding it do anything at this time? - If not, is this still a planned feature or should I forget I read about it? And maybe should the wording on /shun be updated? Hidden is one of those planned features that I never got around to implementing. It shouldn't be that hard to add. Probably just a small adjustment to WHERE clause of the main query that does the timeline. That looks like an interesting place to start hacking on fossil, so I'll take that as a challenge :) Thanks for the answer, T ___ 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] Status of the hidden tag
On Fri, Aug 9, 2013 at 1:39 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Aug 9, 2013 at 10:32 PM, Themba Fletcher themba.fletc...@gmail.com wrote: I don't shun things, but there are times where I'd like to clean up the main timeline view for public (aka customer) consumption. I can see that adding a 'hidden' tag is suggested as a better alternative to shunning. My questions are: i can't answer your questions (i have never shunned) but can offer a (sub-optimal) alternative: disable the timeline view for them and maintain a hand-written changelog in the wiki or embedded docs for them. Yep, that would work. I could also, since I was thinking specifically of using the RSS feed, maybe cobble something together out of the JSON api -- basically just a new version of timeline.rss with any hidden checkins removed. Food for thought, thanks. ___ 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
i _strongly_ recommend against keeping the repo db in the same dir as a checkout. Very little can go wrong when they're separated and lots can go wrong when they're not. Wholeheartedly concur. In just over two years of daily usage I've lost data exactly once and that was due to having my repo too close to my checkout and there was an unfortunate typo involving the rm command ... Another advantage to a single repos directory is if you run something like the following automatically on startup $ fossil server --localauth -P 8080 /home/tif/Projects/repos you will never have to type 'fossil ui' again. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] best practices during a large rewrite
Hi all, I recently got a contract to rewrite a large (web) application. The intent is to transition, at a measured pace, from a large collection of hand-written, framework-free php files to a structured setup with a nice MVC framework, etc. So far so good. I've got all the original source in a fossil repo and it has a pretty rich history as I've been maintaining this system for the last year or so. Moving this to the framework I've chosen will involve, up front, moving every single one of the exisiting source files to a new location deeper in the project hierarchy. The files will then be slowly replaced as their functionality is added to the new system in the appropriate place. I'd love to be able to do this project with hotfixes continuing on trunk as the deployed version evolves and having all of the restructuring take place on a super massive v2 branch, but I'm anticipating a few problems: * Merging updates from trunk to v2 -- cherrypick isn't going to work very well when the names don't match anymore, is it? * What should I expect after I've deleted a file on v2 (having replaced its functionality) and then merge back some updates from trunk containing a change to that file? Just a plain old merge conflict or should I expect and watch for the file to reappear on the branch after being previously deleted? * Anything else you can foresee? Has anyone out there tried a complete project restructuring on a branch with any success, or is the default workflow to just spin up another repo and synchronize changes by hand? Any other thoughts or input? Thanks, Themba ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Status of the hidden tag
From fossil's /shun page: Do not shun artifacts merely to remove them from sight - set the hidden tag on such artifacts instead. The only other reference I could find while searching this list was a note from drh (circa 2009 or so?) noting that it had not been implemented yet. Is this still the case? I just tried, via the web interface, adding a hidden tag to a checkin on one of my mistake branches and the timeline still showed the item. Perhaps there's a setting I've missed -- or perhaps something else? $ fossil version This is fossil version 1.26 [674a24a360] 2013-07-20 16:43:45 UTC Best Regards, Themba ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] bugreport: fossil mv reports success when file does not exist in repo
Hi all, I just encountered the following behavior: $ fossil mv garbage garbage2 RENAME garbage garbage2 $ fossil ls | grep garbage $ fossil version This is fossil version 1.25 [0e5f0da7eb] 2013-03-06 02:18:20 UTC The file garbage is of course not in the repo at all, but fossil appears to be telling me it renamed it successfully. Fossil status / changes / etc seem to be fine (ie none of them report the move). Best Regards, Themba ___ 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] I do want open --keep to be possible with updates
'fossil update -n' will just show you what would change if you ran fossil update. 'fossil sync' will just sync the repo and not make any changes but not make any changes to your checkout. Fwiw, I believe update with -n syncs as well. Hth, T On Thursday, February 21, 2013, K. Fossil user wrote: Hello, fossil open myrepo.fossil --keep fossil update ## updates downloads files and they are stored in the current directory. Can't fossil do something like : fossil update --keep # so NO files are written in the current directory ? Best Regards K. ___ 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 svn conversion gets confused if last svn checkin is on a branch
On Tue, Feb 19, 2013 at 8:07 PM, Warren Young war...@etr-usa.com wrote: snip The request, of course, is for the Fossil Git importer to either have some improvement that makes it smarter about recognizing the *true* trunk, or at least a flag that lets you tell it the trunk's tag name if it guesses wrong. Does the following help in your case? tif@:~$ fossil help settings | grep main-branch main-branch The primary branch for the project. Default: trunk ___ 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] Tip: tinkering with/prototyping fossil UI changes
Yep, it's a game changer :) I just figure this one out last week: Save As - Webpage Complete will save your current state (albeit in the horrible page.html with a collection of files in page_files/* format). But you can save before / after a huge mocking up session and then run diff. This usually gets about 90-95% of the changes for me. Oh, you can also right-click the element in the inspector and force its state (to :hover etc) and even set a javascript breakpoint if the element or its children are modified ie. by an ajax call. On Wed, Feb 20, 2013 at 12:43 PM, Stephan Beal sgb...@googlemail.com wrote: i just learned this today and am having fun with it now in the fossil UI... In Google Chrome (or Chromium), open the Fossil web page, then the dev tools (Ctrl-Shift-I for PC-like keyboards, no idea for Mac). Right-click on some UI element in the fossil page when you would like to move somewhere else. (For example, the timestamp in the top/right under the user name.) Click the inspect element menu to jump to that item in the dev tools DOM view. Now, in the DOM view, _drag_ that element to another location in the DOM (e.g. drag the clock element above the user's name). Voila - the HTML view is immediately updated. Of course, the changes only last until the page is reloaded, but this is a really easy way to tinker with potential changes to the fossil UI before delving into the C code (or the CSS code, or custom JS code which moves the elements around). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] CORS requests and the JSON API?
I should clarify a bit Stephan -- it was not specifically a doubled
Access-Control-Allow-Origin header that destroyed my week but rather was a
doubled Content-Length header. I was in the same boat as you though. If I
explicitly added it it was doubled, and if not it wasn't correct (on that
server config anyways -- which I did not have good control over).
But doubled headers in general are now considered a security risk
so current Firefox and chrome treat them harshly. I did find a blackhat
paper describing an exploit using doubled Access-Control-Allow-Origin --
but again with the eye pain.
Good luck :)
On Fri, Feb 8, 2013 at 12:48 AM, Stephan Beal
sgb...@googlemail.comjavascript:_e({}, 'cvml',
'sgb...@googlemail.com');
wrote:
On Fri, Feb 8, 2013 at 2:26 AM, Themba Fletcher
themba.fletc...@gmail.comjavascript:_e({}, 'cvml',
'themba.fletc...@gmail.com');
wrote:
Whoops -- please ignore the previous stuff for now.
You have a doubled Access-Control-Allow-Origin header in your response:
i saw that but it's not my fault - if i don't configure Apache to send
this header then it does not. If i do configure it to send the header then
it sends it twice. No idea why, but it seems harmless enough for now.
1.
Doubled headers have absolutely destroyed me in the past -- I'd start
there ...
Or maybe it's not harmless. i'll see what i can do about that, then.
Thanks for the tip.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org javascript:_e({}, 'cvml',
'fossil-users@lists.fossil-scm.org');
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CORS requests and the JSON API?
If I understand correctly the OPTIONS request is forced by the fact that your POST's content-type is application/json -- Any request that's not a Simple Request gets a preflight because the W3C says so. Simple requests are defined as (emphasis mine): - Only uses GET or POST. If POST is used to send data to the server, the *Content-Type of the data sent to the server with the HTTP POST request is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain.* - Does not set custom headers with the HTTP Request (such as X-Modified, etc.) according to https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-USredirectslug=HTTP_access_control So I think the resource -- fossil in this case -- is going to have to respond properly to a CORS preflight OPTIONS request. I started reading through this http://www.w3.org/TR/cors/#resource-preflight-requests and then my eyes began to bleed and I had to stop :) On Thu, Feb 7, 2013 at 10:20 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, i am trying, as a proof-of-concept, to host a fossil repo using the new Google Drive feature of being able to host HTML/JS/CSS (as a basis i'm using an existing custom fossil UI built on the JSON API). It's _almost_ working but falls flat due to CORS (cross-origin calls) limitations and i'm not sure what else i can do/should be doing to help this along. i'm looking for assistance from anyone with CORS experience, specifically with making jQuery work properly with CORS AJAX calls in an HTML5 page. The page is here: https://googledrive.com/host/0B-LwmfRxDIPvTFhJQl9FTVNvWTQ/index.html (warning: it currently throws a lot of alert() dialogs due to failed ajax connections.) If you enable your debuggering tools while loading it you can see that the requests to the remote fossil JSON back-end are OPTIONS requests instead of GET/POST. This is where it is falling flat. i am (due to inexperience) unsure whether or not i need to hack fossil to do something specific on such an OPTIONS request. Even better would be to get jQuery to _stop_ sending an OPTIONS request and just send GET/POST as i tell it to in the first place. (i.e. it's trying to be too clever and i need it to stop doing so.) So far i have not found the magic combination of options to make this work. i switched from a jQuery-based AJAX back-end to a plain old XHR-based one but the results are similar (but not quite the same). With plain XHR, _some_ requests are being sent as OPTIONS and _some_ are being sent as GET/POST, and all of them (regardless of method) are failing and i'm not sure why. i have configured my Apache to set these headers: Access-Control-Allow-Headers: x-requested-with Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Origin: * Do any of you have a hint about what i might try next to get this running? :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] casE-senSitive?
What about setting up diff-command to suit, then exporting the diff to a patch file, fossil revert and then apply the patch? On Wed, Feb 6, 2013 at 10:25 AM, sky5w...@gmail.com wrote: Yes, I definitely have mixes of meaningful and non-meaningful [white space, case sensitive, empty lines] diffs to review. While I would love to 'one-tool it' with fossil's diff tech, I find it way easier to pop into winmerge and all its ignore goodies. Maybe I'm too optimistic to expect that much power in one tool? Thanks for Fossil! On Wed, Feb 6, 2013 at 12:50 PM, Themba Fletcher themba.fletc...@gmail.com wrote: So sounds like the problem you're trying to solve is that * you have lots of *real* changes to a set of files * most of those changes are meaningless in your environment * so you're trying to separate the signal from the noise. You can use fossil set diff-command 'diff -iw' to ignore case on the diffs. Then either walk through the diffs looking for meaningful ones to commit or look for bare filenames in fossil diff's output and revert them. This is tedious I know. In my case I had to handle lots and lots of whitespace changes mixed in with some meaningful (and potentially broken) actual changes. There are some big problems with this. You will probably get lost if you have lots of files, so I've tried in the past immediately committing the unknown state to a separate branch and then sorting it there. This was a bit tidier and I was better able to break the changes up in smaller pieces, but at the cost of lots of --from and --to in the diff commands. You will probably run into problems when there are both meaningful and meaningless changes in the same file. I certainly wouldn't try it without both branches checked out in side by side terminals, but if you're careful you can eventually end up with a meaningful diff when you merge back to trunk. Good luck, and don't forget to 'fossil unset diff-command' when you're done or I'm pretty sure you'll end up with an accidental mismatch between the commit and what you see in the diff at some point. On Wed, Feb 6, 2013 at 8:57 AM, sky5w...@gmail.com wrote: Well, I agree, but the diff tools I use always have an 'ignore case' option. Seems logical to me that would be an option in fossil also. Unless text vs binary file assignments are super difficult? While I prefer to seek the root of a problem, I cannot guarantee syntax highlighting of source code. I had ~50 diffs to review that involved d vs D and e vs E. :(( The danger is I get lazy and skip a real diff. On Wed, Feb 6, 2013 at 11:16 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Feb 6, 2013 at 10:20 AM, sky5w...@gmail.com wrote: The problem arises from code edits without syntax highlighting. So 'PI2' might be 'pi2' and fossil traps this as a diff. Because it is a diff. 'p' and 'P' might mean the same thing in some contexts, but that does not mean they are themselves the same thing. There are in fact different. And changing one to the other is a change to the file. This shall always be the case with Fossil. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] casE-senSitive?
On Tue, Feb 5, 2013 at 6:56 PM, sky5w...@gmail.com wrote: Hi, I noticed I am getting simple case sensitive differences despite having [ ] case-sensitive unchecked in local and remote repos? Anything else I need to do? It sounds like you're reporting that the file *contents* differ in case as opposed to the file names. If that's your report -- the case-sensitive flag only affects the file name comparisons: $ fossil help set snip case-sensitive If TRUE, the files whose names differ only in case care considered distinct. If FALSE files whose names differ only in case are the same file. Defaults to TRUE for unix and FALSE for windows and mac. If not -- sorry to clutter the discussion :) Themba fossil version 1.25 [80bf94e0f7] 2013-01-18 21:34:21 UTC Thanks for fossil! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Right way to try something new and save/revert?
On Fri, Jan 25, 2013 at 2:59 AM, Gilles gilles.gana...@free.fr wrote: On Wed, 09 Jan 2013 12:10:35 +0100, Gilles gilles.gana...@free.fr wrote: Am I correct in understanding that this is the right way to proceed to try some new code, and either save it (whether it works or not, just as a track-record) or discard it? I have another question: fossil branch ls lists branches available in the repo, but is there a command to list all the files/revisions that have been commited to the experimental branch? I think 'fossil diff --brief --branch experimental' might be what you're looking for. Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Writing Linux kernel-style commit messages in Fossil
On Wed, Dec 19, 2012 at 4:14 AM, Arnel Legaspi jalespr...@gmail.com wrote: Hello, Is there a way to have Linux kernel-style commit logs display the way they should be in the Fossil web UI? By Linux kernel-style commit logs I mean the way Tim Pope described it below: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html At the moment, multiple-line commit messages show up shortened in Fossil (see http://www.fossil-scm.org/index.html/info/64868f2b98 for an example). What we would like to see is to have only the summary line be displayed on the Timeline page, and to have both the summary line and the rest of the commit message after the blank line show up on the specific commit page instead (when you click on the hash in the Timeline page). +1 from me on this feature request. I'd definitely appreciate the ability to use the commit title, 2 X newline, more details style of checkin message if it formatted nicely in fossil. If there's no way to currently do so , we'd like to make a feature request for it. Thanks! --Arnel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File moves reported in commit as file deletion!
On Mon, Dec 17, 2012 at 12:58 PM, K k...@lightpowered.org wrote: If you cannot provide justification for this behavior snip I'm a bit confused by the tone of some of the messages on the list lately. This could have as easily been worded as a polite bug report, but instead comes across as aggressive and intellectually challenging. There seem to be a lot of people ready to tell Richard that he's doing it wrong lately, and I am starting to resent it. I could silently unsubscribe of course, but that misses the point. He's incredibly responsive to requests on here, and abuse leveled directly at the primary maintainer of a piece of software does nothing but make reading the list a job rather than a pleasure for him, to the detriment of all of us in the end. Please watch the tone of your posts. Spoken without any authority, but sincerely as a fellow user of this software, Themba Fletcher ___ 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] Obvious solution to the rm/mv problem?
On Fri, Dec 14, 2012 at 5:29 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Dec 14, 2012 at 7:20 PM, Jan Danielsson jan.m.daniels...@gmail.com wrote: Hello, It seems that some of those who are opposed to changing the behavior of rm/mv are reaching a consensus that the names rm and mv were poorly chosen, because they have a Unix connotation, and rename and move has been suggested instead. So -- is there any reason we can't have both? mv/rm - change to principle of least surprise move/remove - behaves like current mv/rm That way we all get what we want .. no? We have had (for a long time) commands delete and rename. rm is just an alias for delete and mv is an alias for rename. It would not be that hard to change just rm to remove files from disk (if it is safe to do so) but leave delete as the current behavior. Seems like a reasonable suggestion. Could I humbly suggest unmanage for the name of the remove-from-repo-and-leave-the-disk-alone command? This would be consistent with the status messages emitted by fossil (I think on merge?) and it's pretty clear from its name what it would do. This could leave us with the following commands: 1. unmanage -- remove from repo 2. delete -- unmanage and attempt to bring the disk to that state 3. rename -- change the name / path of a file in the repo 4. move -- rename as above, and bring the disk up to date I think this could be a pretty nice middle of the road compromise. As for what rm and mv are aliased to at that point -- I for one don't care. It's the continued existence of known safe (repo only) commands that keeps me smiling. Thanks, Themba -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] Improvements to side-by-side diff
I've been meaning to post this for a while. On every browser except
firefox, at least with my installed fonts, the side-by-side diff container
overflows the body resulting in the body's border being visible as a
vertical gray line behind the diff content.
This will fix that, if you'd like to have it. Nothing special here, just
bog-standard css repeated in blogs all over the net:
Index: src/style.c
==
--- src/style.c
+++ src/style.c
@@ -961,10 +961,14 @@
{ div.sbsdiff,
side-by-side diff display,
@ font-family: monospace;
@ font-size: smaller;
@ white-space: pre;
+@ background: white;
+@ display: inline-block;
+@ zoom: 1;/* IE 6/7 substitute for inline-block */
+@ *display: inline; /* IE 6/7 substitute for inline-block */
},
{ div.udiff,
context diff display,
@ font-family: monospace;
@ white-space: pre;
The lines commented as IE6/7 workarounds are that, but for me at least they
seem to be required or else IE8 chokes on it. Probably has something to do
with the size of the inline-block element.
Tested with your links above on IE7-9 (IE9 in its compatibility modes, so
not the real thing but should be close enough), latest firefox, and latest
chrome.
Best Regards,
Themba
On Fri, Dec 14, 2012 at 6:16 PM, Richard Hipp d...@sqlite.org wrote:
Reposted from fossil-dev:
OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
OLD:
http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24
NEW:
http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24
Comments, suggestions, and (constructive) criticism are all welcomed.
Also welcomed are examples of diffs that do not perform well using the new
diff logic.
Note that I will eventually update the Fossil executables on the OLD
machines above, so if you are viewing this more than a week or so after it
was posted (2012-12-14) then the OLD and NEW will likely look the same.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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 Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) ___ 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 Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin c...@apotheon.net wrote: On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote: On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Sorry for the hasty and flippant reply -- poor judgement on my part given the passion involved in this discussion. It seems to all boil down to what's a sane default and how liberal fossil should be about removing a file from the disk. I obviously prefer the current, conservative, behavior, and it's one of fossil's selling points as far as I'm concerned. This discussion has devolved somewhat into a comparison with other systems and speculation about user growth if fossil fails to conform, which I think may be getting somewhat counterproductive. I'd like to return to what I think should be the focus, which is discussing what the right thing is for fossil to do. As a possible compromise, the combination of a '-f' flag to fossil rm with the ability to add aliases (mentioned as a possible feature by Richard recently in another thread if I'm not mistaken) could solve this completely. The default could remain as is, safe and conservative, and the only downside would be the necessity of communicating the option to new users to alias 'fossil rm' to 'fossil rm -f'. I'll of course even volunteer to write the FAQ entry if this becomes a reality (since I don't really have any place mucking about with fossil's internals). Again, my apologies for adding noise earlier to an important discussion. -- 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 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?
Sorry to drag up an old thread, but I'm just checking back in after a lengthy absence. On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek no...@thewordnerd.info wrote: Weighing in on this, finally: It's interesting to me that everyone speculates that this *might* break things for some hypothetical person, and *might* bite someone, but has anyone here ever been bitten by it? It's the what if that bothers me. I use fossil as a safety net to manage an ungodly number of small maintenance projects, so I'm often not the original author of the project, and am almost never really comfortable with the code base I'm modifying. When I sync a code base to my machine and fossil add . --dotfiles I really appreciate the fact that I can trust fossil not to touch the disk if I accidentally add something that I don't want in there and have to remove it. In the presence of shabby and poorly maintained deploy/sync scripts, solo use of fossil, unknown modifications to the master since the last checkin, etc., the consequences of removing something from my local copy could be pretty embarrassing -- ie I could potentially blow away the only working copy of a new cusomer's web app. Not to say that I couldn't adjust to a new set of danger points, but that I do really appreciate fossil's current behavior. And is it not something that fossil revert could undo? Is it? What about: fossil add . (whoops) - fossil rm something fossil commit (take a phone call and forget it's fossil 2.0) sync up Now the files are gone locally, they're gone on the remote site, and fossil revert isn't going to help. This is obviously a workflow / deploy problem at its root, but it's a bit of sloppiness that fossil's current behavior forgives and the proposed behavior would not. I don't mind avoiding the change until a 2.0 release, but I worry about making it a setting, because I prescribe to the idea that settings add complexity both for users and developers. I agree about minimizing the extra overhead of a setting, but I come down personally on the side of it's working fine, so please don't touch it. Maybe my use case varies from the norm, but I don't do fossil rm all that often and, when I do, the extra overhead of having to do Up arrow, Ctrl-A, Alt-D, Return afterwards doesn't bother me at all. I like explicitly taking care of this as a second deliberate step. My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then just change it. There are plenty of settings already, please don't add another, especially for something that we're all speculating might affect someone who can't just revert for whatever reason. So, respectfully disagree. For me it's about not having to learn new rules about when fossil will touch my files and when it will not. Best Regards, Themba ___ 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
On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: hi there, a modest suggestion: snip -- there seems no easy way to get a list of ignored files (as per the `fsl set ignore-glob' setting. in most cases I find that this setting should be part of the global state of the project. in `hg' there is a default file `.hgignore' where the glob patterns can be put. I find this most useful since in this way the ignore patterns can (but need not) be made part of the project state that is transfered to the other side. This should help: http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki snip I'd like to emphazise: this sure is not a complaint but just expression of my opinion that the UI (and in turn adoption of `fossil') might profit from some changes. and I'd like to learn what the community thinks of these issues. are all of them irrelavant? Fossil was the first VCS that I used with any regularity. So, from that point of view, I find when I'm working with bzr, git, and particularly svn that they each seem really idiosyncratic and weird to me. So there's *a* point of view, for what little it's worth. I find fossil to be really scriptable, and over time I've either scripted over the pain points, learned to accept them, or as often as not learned to appreciate them. As a case in point, I too originally found the chattiness of the autosync cycle to be kind of irritating. Over time, however, I've found it provides a bit of peace of mind when the network gets slow or something else happens (unexpectedly large repo?) and I can clearly see that fossil's still doing or trying to do something. Compare git, where you just type git clone and wait, never knowing if you fat fingered the url or if you're slowly filling your drive with 40G of nonsense... Best regards, Themba j. regards, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] suggestion
On Mon, Nov 19, 2012 at 3:46 PM, Themba Fletcher themba.fletc...@gmail.com wrote: On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff veedeeh...@googlemail.com wrote: On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote: On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: hi there, a modest suggestion: snip -- there seems no easy way to get a list of ignored files (as per the `fsl set ignore-glob' setting. in most cases I find that this setting should be part of the global state of the project. in `hg' there is a default file `.hgignore' where the glob patterns can be put. I find this most useful since in this way the ignore patterns can (but need not) be made part of the project state that is transfered to the other side. This should help: http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki Grrr. sorry for the rtfm -- I meant to add more here but hit send instead At the very bottom of the page you'll find a general discussion about versionable settings and specific reference to the .fossil-settings/ignore-glob file, which is exactly what you're looking for I believe. Themba snip I'd like to emphazise: this sure is not a complaint but just expression of my opinion that the UI (and in turn adoption of `fossil') might profit from some changes. and I'd like to learn what the community thinks of these issues. are all of them irrelavant? Fossil was the first VCS that I used with any regularity. So, from that point of view, I find when I'm working with bzr, git, and particularly svn that they each seem really idiosyncratic and weird to me. So there's *a* point of view, for what little it's worth. I find fossil to be really scriptable, and over time I've either scripted over the pain points, learned to accept them, or as often as not learned to appreciate them. As a case in point, I too originally found the chattiness of the autosync cycle to be kind of irritating. Over time, however, I've found it provides a bit of peace of mind when the network gets slow or something else happens (unexpectedly large repo?) and I can clearly see that fossil's still doing or trying to do something. Compare git, where you just type git clone and wait, never knowing if you fat fingered the url or if you're slowly filling your drive with 40G of nonsense... Best regards, Themba j. regards, joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] colorized fossil diff in the terminal
Attached is a simple shell wrapper around fossil diff that colorizes the output of unified diffs. All command line options are passed on to fossil diff (so you can do --from, --to, --branch, etc), but I wouldn't expect good results for just anything (--side-by-side will break, as will --tk of course). (I'm also piping the output to less at the end because that's my habit but it's easy to remove of course). When I wrote this I tried to match git's diff colors as closely as possible. I've since realized that I actually had a custom diff color scheme in my (inherited and uninspected) .gitconfig, so the only thing I can say about the colors is that I like them and that they're pretty easy to customize. This has so far been lightly tested on exactly one (linux-based, of course) machine but seems to work pretty well for me so far. Criticism and feedback welcome, and I hope it's useful to somebody. Themba f-diff Description: Binary data ___ 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] colorized fossil diff in the terminal
On Sat, Nov 3, 2012 at 5:25 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Nov 3, 2012 at 4:33 AM, Themba Fletcher themba.fletc...@gmail.com wrote: Attached is a simple shell wrapper around fossil diff that colorizes snip Criticism and feedback welcome, and I hope it's useful to somebody. Cool script. Works for me. But I'm going to stick with the built-in --tk option to the fossil diff command that was added about a month ago (and appears in the 1.24 release.) Do you know about that one? fossil diff --tk fossil diff --tk --unified I'm ashamed to admit that that by the time I found the --tk option I was half done with the script, and it never crossed my mind that I could pass the --unified flag to it. I do have quite a bit of time invested in my terminal based workflow at this point (for example the fonts and background colors all match my editor, and some other trivial stuff that makes the mode-switch to a Tk window a little jarring) so I do prefer a fully text based solution, but I do have to say that the new Tck/Tk diffs are nice and certainly much more accessible than the way I'm doing it. So between being half done, the above mentioned text bias, and the fact that my fingers have already grown accustomed to typing f-diff (I used to just pipe it to less -S) and still getting to use 'q' to end the diff rather than Alt-F4 I just finished the script instead of adapting to the new regime :) On the other hand, the Tcl/Tk based solution is (I assume) taking its cues directly from fossil's diff engine, so at least it can be counted on to always add its color correctly... The above requires that you have Tcl/Tk installed on your system. Any reasonable version of Tcl/Tk will do. Tcl/Tk is installed by default on Macs, so you should be good there, and is included by default on most linux distros, if I'm not badly mistaken. Just for reference, Tcl/Tk is installed in Ubuntu 12.04 by default -- or at least enough of it that the new diff mode does seem to work. It doesn't always scale itself appropriately (it's pretty narrow), but this is likely due more to my poor line-length discipline than anything else. Themba ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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 add
On Mon, Oct 29, 2012 at 5:53 PM, K k...@lightpowered.org wrote: Is there a way to see what has been done to a repo since the last check-in? Some kind of an overview of any changes which have not yet been checked in. fossil status, fossil changes will both work For example, I cannot remember if I've already added a new file with fossil add file.c. I was going to add some files for my next check-in but I've since decided to wait until the next check-in. Therefore I need to: * Verify I've not done fossil add file.c. * If I have done fossil add file.c, how to undo it? I'd use fossil rm file.c, though I think in this case fossil revert file.c would also work ^K ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [v123 - Windows] Timeline view does not respect CRLF's in commit comments?
I've not seen or heard of a way to do what you asked for, and I went on a hunt for just that about a year ago. You can, if you wish, visit admin:timeline in the ui and check allow block markup ... This will let you use brs and such in your commit messages, but the raw HTML will still show up in the cli timeline. (This next bit is slightly preachy - my apologies in advance) I've found over time that this limitation has caused me to habitually use the -m flag with an inline commit message. This has limited my commits to only what I can describe in one line, and forced me into a workflow where I use small branches much more frequently, grouping small changes Into coherent sets. I can't say whether this limitation is by design or by happy accident -- but either way it has resulted in my using fossil in a more structured way, giving me a better and cleaner picture of my code over time. So a net win for me. Best regards, Themba On Sep 30, 2012, at 19:43, sky5w...@gmail.com sky5w...@gmail.com wrote: Hi, searched email history and couldn't find an answer... Admittedly, this is a nitpick but I really want my Timeline view to retain the comments I enter at commit time. Ex. # Since no default text editor is set using EDITOR or VISUAL # environment variables or the fossil set editor command, # and because no check-in comment was specified using the -m # or -M command-line options, you will need to enter the # check-in comment below. Type . on a line by itself when # you are done: 2012.09.30 1) Changed this... 2) Broke that... . New_Version: d742fd95965ddb1a4f2d6bba36247a9f01d22a86 fossil ui SHOWS THIS Timeline... 22:23 [d742fd9596] Leaf: 2012.09.30 1) Changed this... 2) Broke that... (user: sky5walk, tags: trunk) INSTEAD OF: 22:23 [d742fd9596] Leaf: 2012.09.30 1) Changed this... 2) Broke that... (user: sky5walk, tags: trunk) Thanks for Fossil! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug in interaction between partial commit and chmod
Thank you. This checkout behaves as I would expect. Since this area of fossil is a bit confusing would there be any interest from your end in a patch for the documentation to more thoroughly explain it? (My apologies in advance if it's already explained there -- but I didn't see it thus this offer). Thanks again, Themba On Tue, Sep 25, 2012 at 4:56 AM, Richard Hipp d...@sqlite.org wrote: Please try Joe's fix at http://www.fossil-scm.org/fossil/info/33ffb32cb8and let us know whether or not this clears your problem. Tnx. On Mon, Sep 24, 2012 at 5:22 PM, Themba Fletcher themba.fletc...@gmail.com wrote: Hello all, I came across this weird case a couple of days ago: 1: tif@whiskey-five:~$ fossil version 2: This is fossil version 1.23 [5253e0a791] 2012-08-23 21:18:51 UTC 3: tif@whiskey-five:~$ fossil init foo.fossil 4: project-id: 49688f237979eb312a68fe32b7cdad04ddad7cec 5: server-id: e579f16a82655c6ab4a8aff2478bc6b96a70624f 6: admin-user: tif (initial password is 563053) 7: tif@whiskey-five:~$ mkdir foo; cd foo 8: tif@whiskey-five:~/foo$ fossil open ../foo.fossil 9: tif@whiskey-five:~/foo$ touch a.sh b.sh c.sh 10: tif@whiskey-five:~/foo$ fossil add . 11: ADDED a.sh 12: ADDED b.sh 13: ADDED c.sh 14: tif@whiskey-five:~/foo$ fossil commit -m initial 15: New_Version: ef4abd6d038f68f3f4db8959ace07c186e39f7f7 16: tif@whiskey-five:~/foo$ chmod a+x *.sh 17: tif@whiskey-five:~/foo$ fossil changes 18: tif@whiskey-five:~/foo$ echo bar a.sh 19: tif@whiskey-five:~/foo$ fossil changes 20: EDITED a.sh 21: tif@whiskey-five:~/foo$ fossil commit -m 'changed a' a.sh 22: New_Version: d4bc5fa8123d99b03d87aee925920d515c8c97e7 23: tif@whiskey-five:~/foo$ fossil ui 24: Listening for HTTP requests on TCP port 8081 25: Created new window in existing browser session. 26: ^C 27: tif@whiskey-five:~/foo$ rm *.sh 28: tif@whiskey-five:~/foo$ fossil checkout trunk --force 29: a.sh 30: b.sh 31: c.sh 32: tif@whiskey-five:~/foo$ ls -l 33: total 4 34: -rwxrwxr-x 1 tif tif 4 Sep 24 13:32 a.sh 35: -rwxrwxr-x 1 tif tif 0 Sep 24 13:32 b.sh 36: -rwxrwxr-x 1 tif tif 0 Sep 24 13:32 c.sh 37: tif@whiskey-five:~/foo$ fossil timeline 38: === 2012-09-24 === 39: 20:31:13 [d4bc5fa812] *CURRENT* changed a (user: tif tags: trunk) 40: 20:30:17 [ef4abd6d03] initial (user: tif tags: trunk) 41: 20:29:33 [89590aa546] initial empty check-in (user: tif tags: trunk) 42: tif@whiskey-five:~/foo$ fossil diff --from ef4abd6d03 --to d4bc5fa812 43: Index: a.sh 44: == 45: --- a.sh 46: +++ a.sh 47: @@ -0,0 +1,1 @@ 48: +bar 49: On line 23 (fossil ui), if you navigate to the checkin page it shows the following: Modified a.sh http://localhost:8081/finfo?name=a.sh from [da39a3ee5e6b4b0d]http://localhost:8081/artifact/da39a3ee5e6b4b0d3255bfef95601890afd80709 to [e242ed3bffccdf27].http://localhost:8081/artifact/e242ed3bffccdf271b7fbaf34ed72d089537b42f [diff] http://localhost:8081/fdiff?v1=da39a3ee5e6b4b0dv2=e242ed3bffccdf27Execute permission set for b.sh http://localhost:8081/finfo?name=b.shExecute permission set for c.shhttp://localhost:8081/finfo?name=c.sh Fossil changes does not report the changes to the execute bit in the CLI (line 17, 19) and neither does fossil diff (line 45). I can see the rationale for not having a special status message just for when the permissions change -- that seems like it would be quite a bit of extra code for a very uncommon case. I do think that a partial commit, however, should probably only commit changes to the files explicitly named. (source-able command list is attached in case that saves anyone any time verifying this) Thanks as always for fossil -- It helps me feed my family, which is all anyone could ask of a great tool, Themba ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bug in interaction between partial commit and chmod
Hello all, I came across this weird case a couple of days ago: 1: tif@whiskey-five:~$ fossil version 2: This is fossil version 1.23 [5253e0a791] 2012-08-23 21:18:51 UTC 3: tif@whiskey-five:~$ fossil init foo.fossil 4: project-id: 49688f237979eb312a68fe32b7cdad04ddad7cec 5: server-id: e579f16a82655c6ab4a8aff2478bc6b96a70624f 6: admin-user: tif (initial password is 563053) 7: tif@whiskey-five:~$ mkdir foo; cd foo 8: tif@whiskey-five:~/foo$ fossil open ../foo.fossil 9: tif@whiskey-five:~/foo$ touch a.sh b.sh c.sh 10: tif@whiskey-five:~/foo$ fossil add . 11: ADDED a.sh 12: ADDED b.sh 13: ADDED c.sh 14: tif@whiskey-five:~/foo$ fossil commit -m initial 15: New_Version: ef4abd6d038f68f3f4db8959ace07c186e39f7f7 16: tif@whiskey-five:~/foo$ chmod a+x *.sh 17: tif@whiskey-five:~/foo$ fossil changes 18: tif@whiskey-five:~/foo$ echo bar a.sh 19: tif@whiskey-five:~/foo$ fossil changes 20: EDITED a.sh 21: tif@whiskey-five:~/foo$ fossil commit -m 'changed a' a.sh 22: New_Version: d4bc5fa8123d99b03d87aee925920d515c8c97e7 23: tif@whiskey-five:~/foo$ fossil ui 24: Listening for HTTP requests on TCP port 8081 25: Created new window in existing browser session. 26: ^C 27: tif@whiskey-five:~/foo$ rm *.sh 28: tif@whiskey-five:~/foo$ fossil checkout trunk --force 29: a.sh 30: b.sh 31: c.sh 32: tif@whiskey-five:~/foo$ ls -l 33: total 4 34: -rwxrwxr-x 1 tif tif 4 Sep 24 13:32 a.sh 35: -rwxrwxr-x 1 tif tif 0 Sep 24 13:32 b.sh 36: -rwxrwxr-x 1 tif tif 0 Sep 24 13:32 c.sh 37: tif@whiskey-five:~/foo$ fossil timeline 38: === 2012-09-24 === 39: 20:31:13 [d4bc5fa812] *CURRENT* changed a (user: tif tags: trunk) 40: 20:30:17 [ef4abd6d03] initial (user: tif tags: trunk) 41: 20:29:33 [89590aa546] initial empty check-in (user: tif tags: trunk) 42: tif@whiskey-five:~/foo$ fossil diff --from ef4abd6d03 --to d4bc5fa812 43: Index: a.sh 44: == 45: --- a.sh 46: +++ a.sh 47: @@ -0,0 +1,1 @@ 48: +bar 49: On line 23 (fossil ui), if you navigate to the checkin page it shows the following: Modified a.sh http://localhost:8081/finfo?name=a.sh from [da39a3ee5e6b4b0d]http://localhost:8081/artifact/da39a3ee5e6b4b0d3255bfef95601890afd80709 to [e242ed3bffccdf27].http://localhost:8081/artifact/e242ed3bffccdf271b7fbaf34ed72d089537b42f [diff] http://localhost:8081/fdiff?v1=da39a3ee5e6b4b0dv2=e242ed3bffccdf27Execute permission set for b.sh http://localhost:8081/finfo?name=b.shExecute permission set for c.shhttp://localhost:8081/finfo?name=c.sh Fossil changes does not report the changes to the execute bit in the CLI (line 17, 19) and neither does fossil diff (line 45). I can see the rationale for not having a special status message just for when the permissions change -- that seems like it would be quite a bit of extra code for a very uncommon case. I do think that a partial commit, however, should probably only commit changes to the files explicitly named. (source-able command list is attached in case that saves anyone any time verifying this) Thanks as always for fossil -- It helps me feed my family, which is all anyone could ask of a great tool, Themba fossil_bugreport_commands Description: Binary data ___ 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] newbie questions - rollback a single file and checkin/checkout/rollback of a whole directory
On Mon, 30 Jul 2012 03:39:57 -0700, David Bariod davidr...@googlemail.com wrote:I don't know if the revert command works for a full directory.It doesn't, but if you happen to be on linux (or at least have grep and xargs in your path) this should work:$fossil ls | grep 'path/to/directory/' | xargs fossil revertI'd definitely recommend doing a sanity check after the first pipe though, at least until you're pretty sure everything is working as you expect:$ fossil ls | grep 'path/to/directory/'-- Themba FletcherDescription/Entity .. (tif@)descriptionentity.com209-591-8096 .. cell 317-435-6970___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] temp files safe to delete?
I had fossil's parent process crash during a commit with autopush on. $ fossil version This is fossil version 1.20 [a75e2d2504] 2011-10-21 12:52:53 UTC Subsequent 'fossil push' seems to have finished the job, and I don't see anything unexpected or suspect any file corruption or anything like that. However, in the directory that contains the local repo I now have two new files: [repo-name]-[big-long-number]-out.http [repo-name]-[big-long-number]-in.http -in is an empty file, and -out appears to be an http POST request, with a file size significantly less than the Content-Length header suggests was planned. Is there any conceivable reason *not* to delete them and pretend this never happened? Thanks in advance, -- Themba Fletcher Description/Entity .. (tif@)descriptionentity.com 209-591-8096 .. cell 317-435-6970 ___ 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 is there both a checkbox and text field for adding tags?
Apologies for bringing this thread back up a week later -- I'm playing catch up on the list today. On Thu, 19 Jul 2012 08:24:03 -0700, Nolan Darilek no...@thewordnerd.info wrote: Asked this before but never got an answer, and it seems like an annoying usability issue. When I'm editing a commit, why is there both a checkbox and a text field for adding a new tag to a commit? Would it not make sense to assume that if I've typed text in the add a new tag box, then I intend to add that tag? If it is left blank, then I don't? There is an accessibility issue in that the form labels aren't matched with entries, primarily because there are no label/ elements. So this screen doesn't render terribly well for screen reader users, and it is unclear whether I am canceling a tag or adding a new one. There are two solutions: 1. Use label elements correctly throughout the UI or I submitted a patch to do just this 6 or so months ago, though sent it directly to Richard instead of to this list (this was probably an error in judgement on my part). I've attached the patch and included some notes below, in case there's any interest. Caution -- the patch is against [9c28bca430] which was current trunk at the time. If there's sufficient interest I'd also be glad to bring the patch up to date. On Sat, 11 Feb 2012 00:16:01 -0800, Themba Fletcher themba.fletc...@gmail.com wrote: snip The attached patch (against [9c28bca430] -- current trunk as of this email) wraps all of the checkbox and radio inputs in the web interface with a label element. For example this: td colspan=6 align=left input type=checkbox name=pclr Propagate color to descendants /td becomes: td colspan=6 align=left label input type=checkbox name=pclr Propagate color to descendants /label /td It worked well across browsers when I tested it, and IIRC handled the activation of the checkbox on text field focus as well. 2. Just drop the checkbox here. While label everywhere would rock, I think this checkbox is redundant, so seems like removing it would be the easiest accessibility fix here. Thanks. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Themba Fletcher Description/Entity .. (tif@)descriptionentity.com 209-591-8096 .. cell 317-435-6970 wrap.patch Description: Binary data ___ 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] feature request: commit option to close merged leaf
On 07/07/2012 04:55 AM, Stephan Beal wrote: Hiho, i've come across the twice the past couple days: - merge something from branch foo to trunk. - edit branch foo and close it. Could fossil's infrastructure support the ability (via an option) to close a merged-in leaf on successful commit after a merge? e.g. fossil merge foo trunk fossil commit -m '...' --close-parents which would then close all non-primary parents (most often just one). This would be helpful for me too, since I tend to have lots of small branches with lifespans in the 1 to 3 day range that only get merged back into the parent once before being closed. For example, when a project is in maintenance mode I tend to get emails like: Please change the following: * foo - bar * baz is broken * add little tiny feature quux So I use a branch to organize the changes around a customer request (branch name is often just 20120101 email Person) and the individual checkins usually map to line items. The real win for me would be that since it's a command line switch my fingers would learn to do this by themselves (like they currently do with 'fossil commit -m --branch branch name'). So far I've failed to teach my hands to consistently reach for the mouse and close the branch promptly, so I end up going back and closing a bunch of old branches weeks later, which sort of confuses the timeline a bit. -- Themba Fletcher descriptionentity.com :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] branch switching [was: import of ancient projects]
On Thu, 2012-03-29 at 19:40 +0200, mlfconv wrote: Hi Ron, thanks for your advice, will try, right now I'm unable to figure out how to switch to a branch or commit into a branch - it seems that if I run: fossil branch new B fossil add somefile.c fossil commit -mcommit --branch B the graph indicator creates 3 separate arrows instead of 2 and it looks as if fossil thinks that I'd like to have 2 distinctive branches both called B. Also creating another branch C actually creates one but when commiting another somefile.c, the arrow pointing from somefile.c tagged 'B' would point to somefile.c tagged'C' however another arrow would point from trunk to branch 'C' but not from branch'C' to somefile.c tagged 'C'. All I'm running are the above mentioned cmds repeatedly and in that order. thanks, Marek To expand a bit on Stephen Beal's answer (because there are lots of different ways to use fossil): I think of fossil checkout (co) as get me a copy of the contents of the repo right here, absolutely and without regard to what I happen to be doing. I tend to use fossil update for almost everything as it seems to be to be more forgiving of my sloppy work habits: tif@whiskey-five:~/Desktop/Projects/ACSS/project$ fossil help update Usage: fossil update ?VERSION? ?FILES...? Change the version of the current checkout to VERSION. Any uncommitted changes are retained and applied to the new checkout. snip The -n or --nochange option causes this command to do a dry run. It prints out what would have happened but does not actually make any changes to the current checkout or the repository. So if I've changed something but realize it belongs in a different branch than I happen to have open fossil update lets me change branches and brings the new changes with it. If my spidey sense starts tingling I'll do a fossil update branch_name -n to make sure no funny business is about to happen. So I only ever use fossil checkout immediately after making a new working directory and doing a fossil open. I had it (fossil co) overwrite a couple of files early on in my learning curve and I've been gunshy about using it on a working repo since. To get what you are looking for above you can do it several ways: fossil branch new B fossil update B fossil add somefile.c fossil commit -m commit or, more simply: fossil add somefile.c fossil commit -m commit --branch B Which is how I tend to work. In either case fossil status will show your working directory is now tracking branch B. The breakdown of the commands you gave (assuming you started in trunk) is as follows: fossil branch new B -- just create a branch named B fossil add somefile.c -- add somefile.c to the repo in the currently checked-out branch (assuming trunk) fossil commit -mcommit --branch B -- commit changes to a new branch named B Just a few words that will hopefully help you on your way. Also -- a bit of unsolicited advice that I wish I had not had to learn the hard way: Early on I thought it might be a good idea to structure my projects like so: project |_ project.fossil |_ file1 |_ dir1 |_ etc It's not. Keep your working repo (assuming you're starting with a single machine - single repo setup like I did) out of your project directory. You'll quickly find that you rely on fossil to keep things for you and that it does a fantastic job, and you may start playing fast and loose with the command link because, after all, no matter what you do your files are safe. There's quite a lot of power in being able to act this way towards a project, but with the repo in the project directory as above you're always one ill advised wildcard on an rm command away from losing everything :) Themba Original Message From：Ron Wilson ronw.m...@gmail.com Time：3/28/2012 19:12 To：Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject：Re: [fossil-users] import of ancient projects On Wed, Mar 28, 2012 at 12:54 PM, mlfconv mlf.c...@gmail.com wrote: basically i don't want Fossil to perform a merge of A2 and B2 (A is the master branch) but insert another file which only acts as a merge and is tagged or labeled as merge but no actual merge is performed by Fossil, A3 is only inserted instead of merging (A3 actually is a file that merged two distinct features from A2 and B2 which is why I want to keep it as historical record instead of doing an actual merge, also B2 evolved into B3 after merge into A3. As long as you don't mind that the revision graph will not show any indication of a merge, you can just commit A3 as is. If you do want the graph to show a merge, you can do a fossil merge, then replace the result with your A3 before commiting. (As I mentioned, fossil merge does not automatically commit the result of a merge. In your case, it would merge changes from B into your working copy of A2, leaving the resulting files for you to
Re: [fossil-users] merge strategy ours
On Tue, 2012-03-20 at 15:04 -0400, Leo Razoumov wrote:
On Tue, Mar 20, 2012 at 09:57, Richard Hipp d...@sqlite.org wrote:
Why not just fossil revert my/file.txt?
For each one of dozens of files in the manifest??
Does this do what you want?
fossil merge foo
fossil changes | head -n -1 | awk '{print $2}' | xargs fossil revert
I tried
$ fossil revert
and it reverts the contents of all files but at the same time it also removes
merge record (clears vmerge table).
All I want is to record a new merge parent without merging in file contents.
--Leo--
On Tue, Mar 20, 2012 at 14:14, Leo Razoumov slonik...@gmail.com wrote:
Hi there,
GIT has a useful merge strategy git merge -s ours that always
chooses our current version over the version being merged in. The
resulting merge has exactly the same files contents as its base
parent. The only difference being that the commit merged in is now
added to the list of merge parents.
How to achieve the same effect in fossil??
For those who wonder why do I need such a thing here is a use case. I
tend to commit very often. In order to prevent polluting public
branches I work mostly on private branches periodically merging the
changes (when they are in good shape) into public branches. When
merging private branch into a public one fossil does not record
private branch as a merge parent (and for a good reason!). Often I do
have a suitable merge parent candidate. How do I trick fossil into
just adding a commit into manifest's P card to make it a merge
parent??
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] clearsign, so what
On Mar 7, 2012, at 19:10, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 18:03, Brian Smith br...@linuxfood.net wrote: On Wed, Mar 7, 2012 at 2:40 PM, Leo Razoumov slonik...@gmail.com wrote: Looking through the fossil source code I found places where manifests are clearsign-ed. But where are signatures verified? They're not. It's designed for when you're auditing check-ins (after, say, a security breach..) That's precisely my question. How do I audit? What command should I use to verify signed artifacts? Preferably, I would like to see something like fossil verify that outputs a list of all clearsign-ed artifacts in the repo annotated with checked OK, check Failed or cannot check (e.g. when key is missing). Recent github compromise gives us some food for thought about fossil's mechanism to ensure data integrity. If I understand correctly, what happened at github was that someone exploited a misconfiguration in the rails framework to insert his own public key as trusted with respect to several repositories. The fossil verify command you proposed above would have had little to no benefit in detecting or sorting out that particular mess. It seems to me cleaning up any specific intrusion is going to be a special case and is probably going to require a trip into the depths of SQLite. I don't really see any benefit to having built-in commands to try to detect a subset of potential intrusions -- that just introduces a larger code base. And every added line of code is a potential security hole in and of itself. Themba --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What you think about this functionality?
On Thu, 2012-01-26 at 15:06 -0500, Richard Hipp wrote: But I can see an --interactive option being useful for the stash apply command, so that you could selectively pull parts of a stash into your working copy. That's a fantastic idea. I have tended to do this by saying fossil stash diff and hand editing the output before applying the patch(es). This works of course but is clumsy and time-consuming enough that more often than I am proud of I end up just skipping the whole process and writing a paragraph for the commit message explaining the unrelated changes. ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 2011-12-21 at 12:25 -0500, Richard Hipp wrote: On Wed, Dec 21, 2011 at 12:08 PM, Nick Zalutskiy pace...@gmail.com wrote: I'm using fossil for the first time, on a new project -- it hurts how pragmatic and elegant fossil is, I had to try it. Over the years, I've developed some habits from hg and git that I can't seems to reconcile with how fossil does things. Can somebody tell me what I'm missing or how my workflow needs to adapt? I seem to be doing two steps for tasks that I preform dozens of times a day and that took one step in both git and hg. rm, mv: Managing files under source control in fossil is tedious, since I have to do every operation twice. One time for fossil and one time for the file system. Ex: $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? Because that is the way CVS works. And Fossil was written to replace CVS as the CM system for SQLite. Oh, you mean a *good* reason for this behavior? Then the answer is no. I fear to change it now, though, since it might really mess up people who are used to the older style. Is this also why fossil (by default, anyways) ignores .dotfiles for example on fossil add? I've been using fossil daily for about six months, and it's my first experience with any kind of version control system. The above behavior, or more correctly the fact that I was not expecting it, caused me to get quite superstitious about parts of my deployment workflow when in fact the root cause was that I had not added the files to fossil that I thought I had. Clearly my fault for missing it in the fine manual, but you'll have that when you're learning a system :) So if there are any changes on the roadmap with respect to how fossil interacts with the filesystem I'd like to also advocate for changes to fossil add and fossil extra to stop ignoring dotfiles. Maybe with a default addition of .* to the ignore glob to maintain backwards compatibility? -- Themba Fletcher ___ 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] Behavior of rm, mv, and changes/extra
On Wed, 2011-12-21 at 18:41 +0100, Dmitry Chestnykh wrote: On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote: I’m in the same boat, doing two actions for every one in other SCM systems, however I do not do it dozens of times a day, so I’ve always just done it with a little gnashing of the teeth. If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. On Wed, 21 Dec 2011 12:25:19 -0500 Richard Hipp wrote: I fear to change it now, though, since it might really mess up people who are used to the older style. I think this won't cause major problems, because the files are version controlled, after all. Or we can have a flag for destructive behavior for compatibility (but habits aside, it's better to have a flag for non-destructive behavior). Well here's a fun thing that just happened: tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ site/common/classes/document_manager.php tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ | xargs fossil add ADDED site/common/classes/#document_manager.php# ADDED site/common/classes/document_manager.php So in the time it took me to type up-arrow | xargs fossil add my editor pulled an auto-save, and fossil added (2) files instead of one. Now I've got: 1. a file in my repo that I don't want 2. and it's not under version control, so I can't get it back if fossil deletes it It's a simple fossil rm away from being solved, but ... Assume a destructive fossil rm, and let's say the file is precious rather than just an autosave file. Lots of ways to get around the auto delete, but not necessarily obvious ones and someone, somewhere is going to learn how it works the first time by having fossil delete their file unexpectedly. Nope, I suddenly find myself a fan of the two step process as it stands. -- Themba Fletcher ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
