On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick <bill.burd...@gmail.com> wrote:
> You could handle that case -- if you shun the current commit, then check > the disk against the current repo contents and mark files that are different > as uncommitted. But to do so would be hard. Shunning is done in the repository database file: "*.fossil". But the information about which files are uncommitted is held in the check-out database file: "_FOSSIL_". And while the check-out database knows about the existance of the repository database, the repository does not know about individual checkouts. So if you run the "fossil rebuild" following the shun from the web interface (which does not know about individual check-outs) the rebuild operation has no way of finding the check-out databases and patching them up. So what you'd probably have to do is modify the "update" command (as well as other similar commands) to check to see if any shunning has taken place and modify their behavior accordingly. It would be tricky to implement and get right. And it would be a lot of work. All for something that is officially discouraged. > > > Bill > > > On Tue, Oct 4, 2011 at 3:15 PM, Richard Hipp <d...@sqlite.org> wrote: > >> >> >> On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal <er...@erlisvidal.com> wrote: >> >>> And that's what I don't understand, how could the Update "overwrote" your >>> changes. >>> >>> This is from the update help command >>> >>> *Change the version of the current checkout to VERSION. Any uncommitted >>> changes are retained and applied to the new checkout. >>> * >> >> >> Because of the shun, Fossil was confused. It thought that the changes had >> been committed, since they had been committed immediately prior to the >> shun. So the files on disk were marked as clean. Hence, Fossil overwrote >> them. >> >> >> >>> ** >>> If you do the same steps, without the shun, just modify some files, >>> update previous. Would that remove my change in the current checkout? >>> >>> Thanks, >>> Erlis >>> >>> >>> On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp <d...@sqlite.org> wrote: >>> >>>> >>>> >>>> On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal <er...@erlisvidal.com>wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> I would like to understand how you lost your changes, but probably >>>>> because I'm ignorant of the internals I'm not able to understand what just >>>>> happened here. >>>>> >>>>> I've read the Shun documentation and the Update documentation, and I >>>>> cannot see how what you said here could occur. >>>>> >>>>> On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp <d...@sqlite.org> wrote: >>>>> >>>>>> >>>>>> "No problem", I thought. I'll just shun it. Which I did. Then I did >>>>>> "fossil update previous" so that I could commit the new version. But >>>>>> (oops) >>>>>> that deleted all of my changes. Everything was lost. Despair and >>>>>> gnashing >>>>>> of teeth followed. >>>>>> >>>>>> >>>>> It looks like the udpate command was the one that actually create the >>>>> problem, but following your entire story, it seems that the situation was >>>>> created by the Shun you did. >>>>> >>>> >>>> Right. I "shunned" my most recent check-in, removing the content from >>>> the repository. Then I did an "update" to the previous check-in so that I >>>> could check in the changes again, but this time with the new smaller JPEG >>>> instead of the massive GIF. But the "update" overwrote *all* of the >>>> changes >>>> I had made over the course of the morning. >>>> >>>> So the "shun" removed the content from the repository. And the "update" >>>> removed the content from the disk. >>>> >>>> Fortunately, there was still one other copy in the undo stack.... >>>> >>>> >>>> >>>>> >>>>> Please (if is not much to ask) can you explain what creates the issue? >>>>> >>>>> Sincerely, >>>>> Erlis >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> -- >> 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 > > -- 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
