Re: [fossil-users] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 5:39 PM, Baruch Burstein bmburst...@gmail.com wrote: On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? Is it possible for 2 manifests to reference common artifacts? ___ 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] Uncommit. Was: Fossil checksum
On Wed, Oct 29, 2014 at 2:19 AM, Ron W ronw.m...@gmail.com wrote: Is it possible for 2 manifests to reference common artifacts? Not only is it possible, it is exceedingly common. This is the usual case, in fact. Whenever you have a file that is unchanged from one check-in to the next, it will be referenced in both manifests. -- 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
Re: [fossil-users] Uncommit. Was: Fossil checksum
On Wed, Oct 29, 2014 at 02:19:37AM -0400, Ron W wrote: On Tue, Oct 28, 2014 at 5:39 PM, Baruch Burstein bmburst...@gmail.com wrote: On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. A Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? Is it possible for 2 manifests to reference common artifacts? It might be a bit extreme, but I think this is good example.. http://netbsd.sonnenberger.org/artifact/9d4de14ab9fb0fac -- Martin G. ___ 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] Uncommit. Was: Fossil checksum
(copy/paste sbeal response in diff't thread) i looked into that sometime in the past year. In theory, once you can pop the top-most commit, you can pop any number (but always from the top). But the devil's in the details - getting each and every cross-reference and delta removed/replaced properly is remarkably difficult. Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? -bch On 10/28/14, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 28, 2014 at 1:31 PM, B Harder brad.har...@gmail.com wrote: I would like an option to pop and discard from a branch tip. Possible? If the repo has been sync'd, then that work would come back to you on next sync (that's understood), but if it hasn't been sync'd, it could be useful. To do an uncommit for a check-in that has not yet been synced, all you have to do is identify the particular artifacts that were added by that commit (the RCVFROM table should be helpful there) and remove them from the BLOB table of the database (taking care to also fix up the DELTA table so that it does not depend on any BLOB that you removed). Then rebuild. You could perhaps omit the rebuild step if you go to the extra work of removing the artifacts from the various other tables in the database. Or maybe you want an uncommit to force a rebuild in order to make it a little more painful, and hence discourage its use. I dunno. If somebody has a patch for the above, we can look at adding it... -- 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
Re: [fossil-users] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 7:05 PM, B Harder brad.har...@gmail.com wrote: Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? In this case it's like a stack and you could only delete from the top (and then the next top, ad nauseum...). You can't remove a link from the middle of the list without invalidating hashes. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Uncommit. Was: Fossil checksum
That's pretty much what I figured... I'll have to dig in and understand cards (and maybe sit down again w/ you and just generally chat) -- but I expect to see a linear relationship. My intuition tells me one ought to be able to pop-and-delete back to origin -- of *course* if a repo has been replicated, a re-sync will (ought to) re-populate... which is fine and good. I guess the details would be: 1) how complex is the structure/relation that needs to be popped to do the operation as cleanly as possible 2) how much cheat room is allowed during the course of this development whereby perhaps a single card/obj could be deleted, and the dangling bits would be culled w/ a [f rebuild] ? 3) I can't think of anything else... -bch On 10/28/14, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:05 PM, B Harder brad.har...@gmail.com wrote: Are references backward, forward, or both ? What I mean is, roughly, is fossil a doubly linked list, or singly, and if single, what direction? In this case it's like a stack and you could only delete from the top (and then the next top, ad nauseum...). You can't remove a link from the middle of the list without invalidating hashes. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 1) how complex is the structure/relation that needs to be popped to do the operation as cleanly as possible On the surface it's really simple because we're guaranteed that there are no references to the top-most item. The details Richard mentioned, e.g. making sure there are no deltas referring to the content you're removing, are what i remember struggling with (on paper). i'll see if i can find the post i wrote about it (on fossil-dev) sometime... 6-9 months ago, i think. 2) how much cheat room is allowed during the course of this development whereby perhaps a single card/obj could be deleted, and the dangling bits would be culled w/ a [f rebuild] ? Only top-most commit (and any unique artifacts it introduced, e.g. new files or deltas vs older ones) could potentially be popped, or at least that's my understanding. 3) I can't think of anything else... You will. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 3) I can't think of anything else... You will. Perhaps looking at how shunning works would help ___ 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] Uncommit. Was: Fossil checksum
Not a bad idea -- this part of the description: Furthermore, all shunned artifacts (but not the shunning list itself) are removed from the repository whenever the repository is reconstructed using the rebuild command. may roughly be what we're looking for. We happen to be applying to a specific artifact only (tip of branch) which shouldn't be any worse than shunning in the middle of a branch, and may be simpler (barring the fact that a tip will have to be properly identified as a tip). Otherwise, there may be clues for what cards/blobs to target -- I also presume that the rebuild (for the case of shun) is to re-rationalize dependencies down the chain -- which won't be necessary w/ working on a tip (?) -bch On 10/28/14, Ron W ronw.m...@gmail.com wrote: On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote: 3) I can't think of anything else... You will. Perhaps looking at how shunning works would help ___ 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] Uncommit. Was: Fossil checksum
On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Uncommit. Was: Fossil checksum
On 10/28/14, Richard Hipp d...@sqlite.org wrote: On Tue, Oct 28, 2014 at 5:17 PM, Ron W ronw.m...@gmail.com wrote: Maybe could be as simple as adding the relevant artifact IDs to the shun list and rebuilding. (Though that would be rather slow (which is not necessarily a bad thing for this feature)). Yep. Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. For that reason (and the extra baggage of the added element to the shun list) I think that shun (proper) is not the ideal long-term solution. -- 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
Re: [fossil-users] Uncommit. Was: Fossil checksum
Actually you might. By pushing a new tip on a branch a modified file X will likely cause the previous version of X to change to delta storage based on the new commit. IIRC. On Tue, Oct 28, 2014 at 2:46 PM, B Harder brad.har...@gmail.com wrote: On 10/28/14, Baruch Burstein bmburst...@gmail.com wrote: On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp d...@sqlite.org wrote: Just be VERY CAREFUL that you don't add an artifact that is also used in some other check-out that you want to keep, because after you shun it will be gone forever. Shouldn't the shunning function/command take care of rebasing any deltas off shunned artifacts? For the purpose of this discussion (pop-and-destroy), I think there will be no deltas to have to accommodate, since we're only working against a tip of any branch. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
