On Sun, Oct 12, 2014 at 10:53 AM, David Mason <dma...@ryerson.ca> wrote:
> On 12 October 2014 06:06, Richard Hipp <d...@sqlite.org> wrote: > > > > No such luck. The artifacts are present in an arbitrary order. It is > > entirely possible that a "push" might involve multiple server round-trips > > and that the firrst server round-trip might send artifacts from later > > check-ins while the later round-trips send artifacts from earlier check- > > ins. A completely separate server process handles each round-trip. > > Ahhh... so you could have a client-server interaction that sent all > the files from a commit and then the connection went down; and the > server repo is perfectly OK, except that checkin doesn't yet exist, > and then in another connection, the manifest gets delivered and > cross-linking happens and the server repo now knows about the > checking, so there really is no "we're done with this commit" point in > the code other than (kind of incidentally) cross-linking. > > Let's try a more explicit example (but sticking to update only > happening on the client and assuming no auto-sync for simplicity): > > Time 1: server & client both have manifest 1 > Time 2: user on client does a commit of file1 which puts file1 and > manifest2 into client repo. > Time 3: user does a push; file1 gets to server; connection fails > before manifest2 gets there > Time 4: user does a commit of file2, which puts file2 and manifest3 > into client repo > Time 5: user does push; manifest 3 gets to server; connection fails > > at this point looking at server you would only see manifest1 - no > file1, no manifest3 (because it's dependent manifest2 isn't there) > I'll have to double-check, but I think manifest3 will still show up even if its parent manifest2 is still missing. Otherwise, your description seems spot on. > > Time 6: new connection, file2 gets to server; connection fails > > still only manifest1 visible at server (i.e. no file1, no file2, and I > presume if I did a rebuild at this point the artifacts for file1 and > file2 would disappear). > > Time 7: new connection, manifest1 arrives, cross-link does its magic > > now manifest2 and manifest3 are visible at server. > > If I've got this right then: > 1) this is very cool.... weird, but cool > 2) I can't prevent the artifacts from going into the repo, so shunning > is really the only option (I could remove them - ah, I could, but then > they could get re-sent). > When you shun a file, it reports the SHA1 hash of that file in the "shun" table of the database, and thereafter refuses to accept it on a push. If the other side resends the file, it is silently discarded. > 3) I can't shun the manifest (because essentially that client would > never be able to commit again, even as the right id), but instead want > to shun all the artifacts mentioned by the manifest, and maybe tag the > manifest in some way so it shows up specially in the timeline. > 4) I am thinking about recovery for valid commits that accidentally > got committed with the wrong id, and I remember that there is a way to > change the id associated with a commit, but I can't find it... any > pointers? (The fallback to re-clone and re-commit would require the > artifacts to be edited or un-shunned, so there's some work to do > here...) > When you say "id" are you talking about the branch that the check-in is part of? You can modify the branch of an existing check-in by going to the "Edit" page for that check-in and entering a new branch name. (The underlying mechanism is that a tag artifact is issued which modifies the displayed attributes of the original check-in. The original check-in is immutable and cannot be changed. But the added tag tells Fossil to display the check-in using a different branch.) We sometimes do this when we make a check-in by mistake. Here is one example of many: http://www.fossil-scm.org/fossil/timeline?c=01c83bfb&y=ci If you click on "Mistake" check-in ( www.fossil-scm.org/fossil/info/01c83bfbbfc), you can see that check-in originally went into trunk, then was moved over to the "Mistake" branch using the "Edit" screen. The edit also changed the check-in comment and background color. The edits were implemented by the tag seen at ( www.fossil-scm.org/fossil/info/42e170fbfed) > 5) the only place I could auto-shun the invalid commit would be at > cross-link time. Which sounds easier than I had been thinking, but I > have one related question: > > If I commit version1 of a file, then version2, then version3 and then > I shun version2, how does it get version1 and version3 since I thought > files were stored as deltas and there would be an in-between version > missing. > The shun operation knows to undelta dependencies before it deletes the shunned file. I think http://www.fossil-scm.org/fossil/artifact/123f0542db2?ln=278 is the specific line of code that does that for you. The shun mechanism is really intended only to remove spam or illegal content. For honest mistakes, I think it is better to just move them off into a "mistake" branch. > > Thanks, > > ../Dave > _______________________________________________ > 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
