> On 25 May 2010 23:38, Eric Junkermann <e...@deptj.eu> wrote: >> On Tue, May 25, 2010 at 10:10 pm, "Michal Suchanek" >> <hramr...@centrum.cz> >> wrote: >>> On 25 May 2010 19:59, Eric <e...@deptj.eu> 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. > > 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 "what will be committed", since the repository doesn't know, you might change your mind, and you might be going to do a partial commit. Regards, Eric _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
