On 26 May 2010 19:58, Eric Junkermann <[email protected]> wrote: > >> On 25 May 2010 23:38, Eric Junkermann <[email protected]> wrote: >>> On Tue, May 25, 2010 at 10:10 pm, "Michal Suchanek" >>> <[email protected]> >>> wrote: >>>> On 25 May 2010 19:59, Eric <[email protected]> wrote: >>>>> >>> ... >>>>> >>>>> But ckout is only available if the server is running in a local >>>>> checkout, >>>>> otherwise it is silently converted to tip and what you see is the >>>>> checked-in version. You don't see uncommitted changes unless you run >>>>> the >>>>> server in a checkout directory tree, which sort-of implies that you >>>>> are >>>>> changing stuff. The main intent was to allow you to see how a set of >>>>> doc >>>>> files is rendered while you are still working on it. See the last >>>>> paragraph of >>>>> >>>>> http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki >>>>> >>>>> This is NOT a bug, it is a useful feature. >>>>> >>>> >>>> This is a bug, it should show uncommited files ONLY when they are >>>> marked to be committed. >>> >>> "marked to be committed"? - do you mean that a "fossil add" has been >>> done? >> >> Yes >> >>> I might work on something, and want to preview it, only to find later >>> that >>> it should be included as part of another file (or thrown away entirely >>> as >>> a bad idea). >>> >>>> >>>> Otherwise what you commit differs from this preview of files you are >>>> working on. >>> >>> Why shouldn't it? All I am doing is looking at a work-in-progress. >>> No-one >>> else is going to see it. When is this going to cause a problem? >> >> I am not particularly interested in how some random files in my >> filesystem would work as fossil doc pages. > > They are not random files in the filesystem, they are in the checkout > tree, where most people would be working on their project.
But most projects would also have temporary or generated files in there so it's not preperesentative of what should be in the repository, either. > >> >> So how do I see how the files that wil be *committed* work together? >> > > By looking at doc/ckout ! That's what it is for. Wanting to distinguish > between things you have done an "add" for and things you haven't is > pointless. The repository doesn't know about them anyway. > > My normal approach is to develop away in the work area without telling > fossil anything at all, until it is time to check in, then I do a fossil > changes and a fossil extra to see what I have actually changed, and decide > whether I might need a partial commit. Then I can do any necessary adds, > renames etc. followed by a re-check and then the commit. And I can look at > doc/ckout whenever I want, and again as part of the checking process. > >> If this feature is for wip-wip files what is for wip files? > > Well, I just don't understand what you are on about, there is only one > level of WIP, and I can see no reason for another. There is no point in Nor do I. But our definition on WIP state differs so there is apparently more than one. > "what will be committed", since the repository doesn't know, you might It does as my patch demonstrates. > change your mind, and you might be going to do a partial commit. Yes, and when I do change my mind I can remova/add the files and preview them again. Thanks Michal _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
