Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)
On Fri, May 27, 2016 at 10:00 PM, Stephan Beal wrote: > On Fri, May 27, 2016 at 6:39 PM, Andy Gibbs wrote: > >>File 3rdparty/chromium/third_party/sqlite/sqlite-src-3080704/manifest - >> part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** >> message elided ** >>File 3rdparty/chromium/third_party/sqlite/src/manifest - part of >> check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message >> elided ** >> > > That's the source of your... troubles is not quite the word (see below). In > fossil, any content which looks like a manifest, is a manifest and will be > treated as such. There is no marking of "that is a manifest" - it's > determined by checking "can it be parsed as a manifest?" > > To quote: > > http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki > > "Any artifact in the repository that follows the syntactic rules of a > manifest is a manifest. Note that a manifest can be both a real manifest > and also a content file, though this is rare." > > [...] > >> So, I certainly don't want to shun this artifact because then I'll lose a >> file from a valid check-in -- isn't that right? > > i believe that's correct. > >> But how can I fix it? > > This is how fossil behaves, so there's nothing to fix :/. Stephan, Thanks, that was exactly the set of answers I was looking for. I now understand the problem and can avoid it in future. Having done some tests it seems that the "fossil rebuild" actually caused the problem -- fossil doesn't cause the manifest file to appear as a timeline entry on commit itself. But Richard, since... > Just to be clear, I consider anything involving shunning to be > out-of-the-ordinary. what then is the best way to clear up the repository history, in particular these to rogue (but it turns out entirely expected) timeline entries? Branch hiding? Cheers Andy ___ 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] Weird cross-contamination between two fossil repositories (and not even talking to server!)
Hi again, I've just discovered something and maybe it is helpful. I checked the "artifact" webpage for both of these rogue artifacts, and I get multiple sources for the artifact in question, e.g.: http://localhost:8080/artifact/f66f7a17b7 Artifact f66f7a17b78ba617acde90fc810107f34f1a1f2e: File 3rdparty/chromium/third_party/sqlite/sqlite-src-3080704/manifest - part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message elided ** File 3rdparty/chromium/third_party/sqlite/src/manifest - part of check-in [079a920cf4] at 2016-03-13 00:00:00 on branch trunk - ** message elided ** Also Manifest of check-in [f66f7a17b7] - Version 3.8.7.4 by drh on 2014-12-09 01:34:36. C Version\s3.8.7.4 D 2014-12-09T01:34:36.054 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f F Makefile.in cf57f673d77606ab0f2d9627ca52a9ba1464146a F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23 F Makefile.msc e31dee24038965fb6269d6d61073fd6b7e331dec F Makefile.vxworks 034289efa9d591b04b1a73598623119c306cbba0 F README.md 64f270c43c38c46de749e419c22f0ae2f4499fe8 F VERSION d7e46e14bd7393d54d19ad900222e5f20d41ea1b ... And the other artifact is the similar. Could this account for the odd behaviour? Fossil has somehow got confused about an actual commit and a manifest file that has been checked in? So, I certainly don't want to shun this artifact because then I'll lose a file from a valid check-in -- isn't that right? But how can I fix it? Thanks again for your help in my hour of need :o) Andy - Original Message - From: "Andy Gibbs" <andyg1...@hotmail.co.uk> To: <fossil-users@lists.fossil-scm.org> Sent: Friday, May 27, 2016 6:26 PM Subject: Weird cross-contamination between two fossil repositories (and not even talking to server!) 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-sync feature. I then made 7 commits, the first of which caused a trunk fork which I then "repaired" by branching the old tip-of-trunk that caused the fork. I then committed two commits to the new branch, then realised that I'd committed the wrong code, so shunned the last two commits, rebuilt the respository, unshunned the sha1 signatures, rebuilt, then recommitted the last two commits using the correct code. Ok, a little complicated but nothing too out-of-the-ordinary, I hope. Except ... now I have two utterly random commits in my cloned repository - both seemingly from the sqlite repository: 2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, version-3.8.7.4) 2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh) Now, it is true that I have a clone of the sqlite respository on my server too ... but I haven't yet synced with the server. Absolutely no server communication has happened since my initial clone. And these odd artifacts were definitely not there (or, rephrased, definitely not showing) when I was mid-way through all of this work, and are not there on the server's copy of the repository either. Unfortunately, I cannot say exactly when these artifacts appeared, but my hunch would be somepoint around the shunning/rebuilding process? Does this even make sense?!? Worse, I am left not sure whether to simply shun the two random artifacts and then push the changes to the repository up to the server. It has taken the best part of a day to get all these commits in and it represents about 6GB of source files (the repository has doubled from ~700 MB to ~1.5 GB) requiring a lot of manual "fossil mv"s to synchronise many moved files (fossil doesn't yet support a git-like auto-mv-detection sadly). Any idea how I can easily check the validity of my repository? I have done the obvious which is to check out each of the recent check-ins and compare them with the original source folders, but what I don't know is whether the structure of my respository is damaged in some way... Help :o) Thanks! Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)
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-sync feature. I then made 7 commits, the first of which caused a trunk fork which I then "repaired" by branching the old tip-of-trunk that caused the fork. I then committed two commits to the new branch, then realised that I'd committed the wrong code, so shunned the last two commits, rebuilt the respository, unshunned the sha1 signatures, rebuilt, then recommitted the last two commits using the correct code. Ok, a little complicated but nothing too out-of-the-ordinary, I hope. Except ... now I have two utterly random commits in my cloned repository - both seemingly from the sqlite repository: 2014-12-09 [f66f7a17b7] Version 3.8.7.4 (user: drh, tags: release, version-3.8.7.4) 2011-05-19 [ed1da510a2] Version 3.7.6.3 release candidate 1. (user: drh) Now, it is true that I have a clone of the sqlite respository on my server too ... but I haven't yet synced with the server. Absolutely no server communication has happened since my initial clone. And these odd artifacts were definitely not there (or, rephrased, definitely not showing) when I was mid-way through all of this work, and are not there on the server's copy of the repository either. Unfortunately, I cannot say exactly when these artifacts appeared, but my hunch would be somepoint around the shunning/rebuilding process? Does this even make sense?!? Worse, I am left not sure whether to simply shun the two random artifacts and then push the changes to the repository up to the server. It has taken the best part of a day to get all these commits in and it represents about 6GB of source files (the repository has doubled from ~700 MB to ~1.5 GB) requiring a lot of manual "fossil mv"s to synchronise many moved files (fossil doesn't yet support a git-like auto-mv-detection sadly). Any idea how I can easily check the validity of my repository? I have done the obvious which is to check out each of the recent check-ins and compare them with the original source folders, but what I don't know is whether the structure of my respository is damaged in some way... Help :o) Thanks! Andy ___ 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 sync doesn't sync
On Thursday, December 03, 2015 9:48 AM, Andy Bradford wrote: Thus said Andy Gibbs on Thu, 03 Dec 2015 08:56:42 +0100: For reference, a single commit may lead to around 100 "round-trips" to then sync with the server (assuming no commits coming back as well). If you are using autosync (the default) then Fossill will first pull, before it pushes. Are these the ``round-trips'' you mean? If so, what is more important to know is how many round-trips are made during the ``push'' synchronization part of the autosync. Though, again, the max-download may have just been a red-herring, and just another clue in the puzzle that helped discover the actual problem. "round-trips" being during the push (i.e. post commit). Sorry I was using the terminology of what was being shown on screen -- not combining the pre and post commit numbers. Ok, this produced a very long list starting thusly: 170716 unreachable artifacts: Should I be worried?! Not yet... Please run: fossil rebuild fossil test-clusters Then we'll get the true picture of whether or not you have something to be worried about. The clusters are only used for sync operations, not clone, so if one goes missing, then it makes it so clients cannot pull new content (the original bug that was fixed). So... doing fossil rebuild then test-clusters on the server results in "all artifacts reachable through clusters". Hooray! However... doing then a sync on my clone, then doing the fossil test-clusters again on the server results in: 170931 unreachable artifacts: 127299 17df491816cdbd40fcbca031950decdf9532 150554 67ad9657662b33a669d87934b6df91a62f71 134125 91fa0dc5528c0595b16c4cc56f9365bfbba0 68008 cc81620bd3ff86379b744e4dae91df8f6175 [...] However, on my clone I get: $ fossil test-clusters all artifacts reachable through clusters Both server and client are running 1.34. Cheers Andy ___ 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 sync doesn't sync
On Wednesday, December 02, 2015 4:40 PM, Andy Bradford wrote: Thus said Andy Gibbs on Tue, 01 Dec 2015 19:14:13 +0100: I am syncing with a single server, and I have made sure all the clients have the same fossil version as the server (actually I've upgraded them all to the latest released version). I have even run "fossil rebuild" on all checked-out repositories and also on the server. Did you upgrade them prior to the problem happening or after? What version were they before the upgrade? I upgraded after the problem occurred. I was running 1.32 on the server and 1.32 or 1.33 on the clients. All are running 1.34 now. Stupidly, I didn't think to keep a copy of the repository files before using --verily. I can certainly let you know when (if?) it happens again. What can I say about my usage patterns? ... I am certainly doing large check-ins, for example, modifying 100s of files at once. A raw check-in manifest file could easily be in the order of 4 MB in size. I am not, however, using private branches or shunning artifacts. I have around 20 public branches, but most are closed. Branch check-ins tend to be small in comparison. Does this help? There was a known bug where a large commit (by large I mean the number of artifacts in the commit) would cause sync problems because some cluster artifacts---which are primarily used for sync optimization---would get lost in the chain on the server. Because the server lost track of a cluster artifact, some subset of artifacts would never be requested for synchronization by the client. This was fixed and as far as we know it hasn't happened again. Here is the previous discussion which eventually led to a fix: http://marc.info/?t=14456583101=1=2 http://marc.info/?t=14456583284=1=2 If you can cause it to happen while running the latest Fossil on both the server and clients (after having used --verily to bring in all the artifacts) it would be appreciated if you can provide steps to reproduce it. Thanks, Andy -- TAI64 timestamp: 4000565f112a ___ 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 sync doesn't sync
On Wednesday, December 02, 2015 5:06 PM, j. van den hoff wrote: On Wed, 02 Dec 2015 16:56:35 +0100, Andy Gibbs wrote: I upgraded after the problem occurred. I was running 1.32 on the server and 1.32 or 1.33 on the clients. All are running 1.34 now. which at least means they were all post 1.30 (in which version the sync bug presumably was fixed) so I would take this as a strong indication that there still is a problem, right? Yeah, I try to keep up to date on the client side. The server is not so regularly updated, but had been running 1.32 since (maybe?) April/May. Before that, maybe it was running 1.28? But my memory is a little shady. HTH, Andy ___ 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 sync doesn't sync
On Thursday, December 03, 2015 5:21 AM, Andy Bradford wrote: Thus said Andy Gibbs on Wed, 02 Dec 2015 16:56:35 +0100: I can certainly let you know when (if?) it happens again. What can I say about my usage patterns? ... I am certainly doing large check-ins, for example, modifying 100s of files at once. That certainly is similar to the criteria for the previous conditions. Before the previous fix I had reproduced it with 1,500 changed files in a single commit, thus resulting in a manifest with a lot of F-cards. I saw in the referenced threads that max-download also had something to do with it: http://marc.info/?l=fossil-users=144565833040818=2 I had a look at the description for max-download (download packet limit) and I'm not sure. The limit is 5MB (M not Mi!) by default it would seem. What I'm not sure about is what this limit exactly applies to - from the description given (I haven't looked in the source code) - i.e. I am pretty sure an individual check-in could easily exceed 5MB of uncompressed diffs for example. Worst case, a single file could have 5MB of changes (or be a new 5MB+ file). I can check further and get concrete numbers if this would help, but I'm assuming this shouldn't be a factor. For reference, a single commit may lead to around 100 "round-trips" to then sync with the server (assuming no commits coming back as well). Though I'm not sure that is actually a requirement for reproducing the problem. At any rate, I had default values for max-download. One thing you can do on the server is run: fossil test-clusters /path/to/project.fossil Ok, this produced a very long list starting thusly: 170716 unreachable artifacts: 127299 17df491816cdbd40fcbca031950decdf9532 150554 67ad9657662b33a669d87934b6df91a62f71 134125 91fa0dc5528c0595b16c4cc56f9365bfbba0 68008 cc81620bd3ff86379b744e4dae91df8f6175 121858 00018c2a5a32810f19ee140a12eaa9e32bec06cd 99123 00022cc63cd3dabb4fcfc62a501994f785c2327d [...] Should I be worried?! Do you have multiple servers to which clients synchronize content before it makes it back to the server where you noticed the problem? Or any other synchronization that happens between peers before making it into the server where you noticed the problem? If so, are all the servers in between 1.30 or newer? Only one server, but about 15 clones spread across development machines and buildbots. I don't know if this helps, but the buildbots sync (i.e. really just pull, but use the sync command) fairly regularly and should generally sync at the same points in the tree. What I notice is that I've only ever had the issue once on one (maybe two) buildbots, but possibly long enough ago that I was using pre-1.30 software then. Generally the buildbots are fine. The development machines are where the problem more often occurs and it seems to happen more often when there is a number of check-ins on the server to be replicated in the clone. I don't remember it happening as part of a sync after a commit, but this could simply be because a repository is synced and checked in the ui *before* doing any major work and so any problems would already be apparent. I am sorry this is awfully vague - it honestly doesn't happen enough that I have a clear memory of all the details! I hope it helps though. Cheers Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil sync doesn't sync
Hi, I'm having an issue which recurs from time to time which is that "fossil sync" doesn't actually do anything, by which I mean I get an output something like this -- Sync with https://. Round-trips: 1 Artifacts sent: 0 received: 0 Sync done, sent: 342250 bytes received: 376 ip: . -- and the latest checkins on the server are not replicated in the local copy. I am syncing with a single server, and I have made sure all the clients have the same fossil version as the server (actually I've upgraded them all to the latest released version). I have even run "fossil rebuild" on all checked-out repositories and also on the server. What is really weird is that some clients are managing to sync correctly, while others have got stuck at different places. They don't get stuck at the same date, so it doesn't seem to be a problematic checkin for example. But once stuck, there doesn't seem to be a way of unsticking them. Of course, deleting the cloned repository and cloning again "fixes" the problem (for a few months or so) but it is a real pain since all the checkouts need to be redone. The repository in question only has about 750 checkins and is about 220Mb large, so this shouldn't be something particularly unusual. Any help gratefully received! Thanks Andy ___ 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 sync doesn't sync
On Tuesday, December 01, 2015 7:17 PM, Richard Hipp wrote: On 12/1/15, Andy Gibbs wrote: Hi, I'm having an issue which recurs from time to time which is that "fossil sync" doesn't actually do anything, deleting the cloned repository and cloning again "fixes" the problem Next time this happens, try running: fossil sync --verily And then let us know if that clears the problem. Yes, wow, thanks! I imagine "verily" as in "truely, really, please, do it!!" :o) One worth remembering, certainly. Could it be documented in the sync help text? Cheers, Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Code beauty
Hi, As an admirer of DRH's code beauty stance, and having been kicking around long enough to remember the markdown debacle, I was a little surprised to see the s-word (!) appear in the fossil repository (src/linenoise.c line 216). Please don't misunderstand me, this is not being facetious, not is it meant to be some sort of weird troll. It is, honestly, just a noise of surprise on my part. :o) I expect it was simply over-looked during import from a 3rd-party. Cheers Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Regression in fossil info command in v1.30
Hi,
Recently updated to fossil v1.30. I've noticed an unfortunate regression that
the fossil info command doesn't work with the -R switch.
I don't know whether this has been spotted by anyone else, but it doesn't seem
to be fixed in trunk. The following patch, partially reverting commit
74ac0c925a, fixes the problem in the interim (but probably not in the best
way!):
--- src/info.c
+++ src/info.c
@@ -201,7 +201,7 @@ void info_cmd(void){
}
/* We should be done with options.. */
- verify_all_options();
+//verify_all_options();
if( g.argc==3 (fsize = file_size(g.argv[2]))0 (fsize0x1ff)==0 ){
db_open_config(0);
Cheers
Andy
___
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] Creating a commit without a parent
On Thursday, January 22, 2015 11:16 AM, Jan Nijtmans wrote: 2015-01-22 10:43 GMT+01:00 Andy Gibbs andyg1...@hotmail.co.uk: I am trying to create a commit without a parent, effectively so that I can create a separate stream inside my repository, in no way linked to trunk and all its branches. Use fossil open --empty . Thanks! That's the one! Thanks also to Stephan and Baruch -- I saw your replies after Jan's came in. Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Creating a commit without a parent
Hi, I am trying to create a commit without a parent, effectively so that I can create a separate stream inside my repository, in no way linked to trunk and all its branches. I cannot find in the documentation how to do this, but I know that it is possible because Jan Nijtmans has managed to do it here: http://fosclipse.sourceforge.net/cgi-bin/core/timeline?n=20b=2012-07-23 Please can someone help me in the right direction?! Thanks Andy ___ 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] Automatic password remembrance in fossil clone
On Thursday, August 28, 2014 6:41 AM, Andy Bradford wrote: Thus said Andy Gibbs on Wed, 27 Aug 2014 18:58:21 +0200: Is there a rationale behind this? Could there be a flag (e.g. -q / --quiet would work!) that can do an automatic yes at this point? I'm not sure about the rationale except perhaps it could be ambiguous. There are potentially other prompts that could be issued during cloning. So simply echoing y into the fossil clone command could be ambiguous. Yes, this is the worst-case high-maintenance option, but surprisingly common! Would the -q / --quiet apply an implied y to the username/password prompt only or would others be impacted? Ordinarily a quiet option would take the default value for any prompts. The prompts have default values already (in this case, simply hitting return means yes). This would actually be quite a neat solution since it seems fossil factors out prompts into their own functions, so on entering the function it can determine whether the -q option has been given and return the default value for that prompt. I would assume, that would mean a blank password where the password is prompted, for example. I would advocate the quiet option being global for all fossil commands. Maybe a --keep-password option would be less ambiguous? Alternatively, if you're scripting the clone with a username/password, have you considered scripting the syncs with the same username/password? I did, but there are a number of different scripts. From a script durability point of view, it would be good, since fossil *can* remember passwords, for it to do so during clone. Cheers, Andy (another one) Andy -- TAI64 timestamp: 400053feb33a ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Automatic password remembrance in fossil clone
Hi, It seems (at least in v1.29) that it is not possible to do a fossil clone with a username and password in the url and automatically remember the password via a command line switch or other approach. What is really interesting is that if you pipe y into the fossil clone command, then fossil doesn't even ask to remember the password. It seems that the user must be prompted, which is a problem when scripting! I've tracked it down in the source code in url.c, function url_parse_local(...) where it explicitly checks isatty(fileno(stdin)) and otherwise doesn't apply the URL_REMEMBER_PW flag at all. Is there a rationale behind this? Could there be a flag (e.g. -q / --quiet would work!) that can do an automatic yes at this point? Thanks!!! Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Problem with fossil sync / pull
Hi, I've recently had the following recurrent problem, namely that using fossil sync or pull does not fully sync or pull from the server. This means branches do get pulled (i.e. it doesn't seem to be an access restriction or network problem), but notably the trunk does not, leaving it at an older version than is held on the server. Doing a fossil rebuild does not fix the problem and each time I have to reclone from scratch. This particularily happens with the one repository, but I may have seen it with another (I can't remember, sorry!). Both server and local machine use the same fossil version: 1.23 I expect I have missed something really obvious! Thanks for any help! Cheers Andy ___ 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] ERROR: file is different on disk compared to the repository during commit
On Friday, August 24, 2012 10:35 PM, Richard Hipp wrote: Fossil keeps track of which files have changed (by default) by looking at the file size and the mtime. If neither the file size nor the mtime have changed, fossil (by default) assumes that the content of the file is also unchanged. Perhaps your edit somehow preserved both the file size and mtime and so Fossil didn't realize that the file had been editing as it started the commit. If that ever happens, you can always fix it by doing: fossil status --sha1sum You can also do fossil setting mtime-changes off and afterwards Fossil will always check the complete file content rather than relying on the mtime and file size. That will be a little slower, but it avoids confusion such as the above. Thanks for the pointers, I've managed to get a commit through! I've looked a little more into how the problem came about: I had merged a branch into trunk, then modified quite a number of the files prior to commit. Among these, one was a new file created during the branch. This one was modified but fossil status showed ADDED_BY_MERGE rather than EDITED. What didn't help was that it was modified, not by hand but by overwriting it with a copy from a backup folder -- this meant that it had a timestamp older than the version merged by fossil (but you were right: by coincidence, the file size *was* the same). (So when I said, I'd not done anything out of the ordinary, I'm afraid I was not so accurate -- I had forgotten all these things, my apologies!) So, anyway, I tried your suggestion re fossil status --sha1sum but this didn't work. I also tried touching the file to give it a more recent timestamp -- this also didn't work. I also tried the fossil setting... but this didn't help directly (but I've left it on for the future!). I also tried modifying the file in a random location (not totally random, but one of the changes made, I un-made), but this didn't cause fossil to realise the file had been modified -- this surprised me. I then modified the *first* line of the file, and then did a fossil status and *now* the file was marked as EDITED so I unmodified the first line, and was able to make the commit without error. So, thanks again for the help: I know what to do next time! (as does anyone else who stumbles across this thread with the same problem!) I am certainly glad of the backup check, though, since otherwise I may have ended up with an incorrect commit and never realised :o) Cheers Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ERROR: file is different on disk compared to the repository during commit
Hi all, I've had the following error, and I don't know why and I don't know what it really means and I don't know what to do about it! (yes, I really don't know!) ERROR: [mefs1a.c] is different on disk compared to the repository NOTICE: Repository version of [mefs1a.c] stored in [file-15c57bdd987a757d] c:\fossil\fossil.exe: working checkout does not match what would have ended up in the repository: e641896af05b54f1481aa9d556a5c24d versus a9b7421a3d7ce833ea78e9cc43b41e18 In terms of how this has come about: nothing out of the ordinary, I assure you: simply editing and committing. Does this mean there is a hash conflict? And what can I do about it? Thanks for any and all help :o) Andy ___ 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] ERROR: file is different on disk compared to the repository during commit
On Friday, August 24, 2012 6:57 PM, Richard Hipp wrote: On Fri, Aug 24, 2012 at 12:45 PM, Andy Gibbs wrote: Hi all, I've had the following error, and I don't know why and I don't know what it really means and I don't know what to do about it! (yes, I really don't know!) ERROR: [mefs1a.c] is different on disk compared to the repository NOTICE: Repository version of [mefs1a.c] stored in [file-15c57bdd987a757d] c:\fossil\fossil.exe: working checkout does not match what would have ended up in the repository: e641896af05b54f1481aa9d556a5c24d versus a9b7421a3d7ce833ea78e9cc43b41e18 In terms of how this has come about: nothing out of the ordinary, I assure you: simply editing and committing. Does this mean there is a hash conflict? And what can I do about it? When you do a fossil commit, Fossil starts a transaction on the underlying relational database. Then it starts making changes to the database to insert your new check-in. After it thinks it has finished, it goes back and does lots of double-checks to make sure that what it added to the database is the same is what you have on disk. It is one of these double-checks that failed. After the failure was detected, the database transaction was rolled back so that no harm comes to the repository. This is a safety feature of Fossil. Apparently when it looked at the file that was committed to the repository as mefs1a.c that file was different from what it saw on disk. The version of the file that it tried store in the repository is now copied into file-15c57bdd987a757d. Can you run a diff on mefs1a.c and file-15c57bdd987a757d and let us know how they differ? Well, it is certainly good to have the safety checks; I wonder how I've tripped it! I did do a quick diff before I posted the original question, and the two files were noticeably different, not in a corruption way, but in a way to imply two different versions of the same file. It was the end of my day so I didn't have a chance to really delve into which older version was causing the conflict (I can check this tomorrow and post again regarding this), but I can certainly say for sure that no file changing was going on while doing the commit (at least as far as I am able to control: i.e. no editor open, etc.). Is it possible that fossil would try to commit a version not actually on the hard-drive? I would have thought not, but the differences were not in terms of line endings or whitespace but really different words (macros were renamed and mefs1a.c had the correct names and file-15c57bdd987a757d had the incorrect/old names). This is what made me think of a hash conflict (however unlikely that may be in actual practice). Does this help? I can get more info tomorrow when I pop into work. Other info: I'm using the latest version of fossil downloaded from the website (1.23 from 8/8/2012) on Windows XP. Thanks! :o) Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil cp?
Hi there, Is there a fossil copy command? There's add, mv, rm but no cp? It's a neat feature of subversion that you can copy a file either from the current checked-out tree or from somewhere else in time and space from the repository, thereby keeping a tracable history intact. At the moment, please forgive me if I've overlooked it, when a file is copied its link to its previous versions is lost and therefore diffs are not easily available, unless the user knows where the previous version is. Would this be a feature worth considering? As a test, I did a bit of a hack in terms of manually updating the vfile table via sqlite and setting 'origname' to the original file, and this sort-of worked, although it probably doesn't work for pulling a copy directly from the repository which may or may not exist as such in the current checked-out branch, and the timeline of course didn't link it correctly either. If it doesn't already exist, and were to be added, in my opinion the copy command should at least support the same syntax as fossil mv, but with an optional --from option: fossil cp ?OPTIONS? ORIG COPY fossil cp ?OPTIONS? ORIG... DIR where OPTIONS can be: --from REVISION = copy from the specified check-in Good idea / bad idea? I'm happy to have a go at patching fossil to support this, if someone can give me an quick overview of how to go about it in the correct way since I'm not to familiar with fossil's internals yet. Cheers Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
