On Fri, 2004-05-14 at 22:02 +0200, Matthieu Moy wrote: > Stefan Reichör <[EMAIL PROTECTED]> writes:
[...] > First : Did you look at the wiki page > http://wiki.gnuarch.org/moin.cgi/xtla Just found it now. I'm also subcribed to this list now :) > >> 1) Tla can fail while doing an update and applying your local changes > >> (eg. if nfs creates a temp. file), this will leave you with a ,,undo-X > >> folder. If you don't see that you might loose your changes and happily > >> continue working on a version without all the work you have just done. > >> It's actually very easy to miss with all the spam generated by tla :) I > >> propose that after update you check if a ,,undo-X (normally X is 1) dir > >> exists and if it does you ask the user if he wants to apply his changes > >> again. > > We need something here. > > Do you know a way to reproduce this behavior ? The best I can think of is to do two checkouts of a version and modify both. One with a very large change and one with a small change. Then commit the large change, do a tla update where you have the small change and try touching a file while it's updating ;) > >> Maybe also have this check when committing. > > It's different. Committing is a read-only operation on the local tree. > If commit fails, you just don't commit, but don't loose local changes. > > The current behavior is when commit fails is : > > * the "*arch-errors*" buffer is displayed > > * If commit is done by C-c C-c in the log buffer, the buffer is not > killed. > > I think it's sufficient. What exactly happens if you try to commit without any changes? > > A question to my contributors: > > Do we have (planned) something like that. > > We *didn't* have, but we should. I'm adding this to the TODO file. > > More generally, we must display the output of 'tla update' and 'tla > star-merge' in a user-friendly way. That would be very nice. > >> 2) A way to specify which files to commit (maybe I have just not found > >> this function yet). > > > > Matthieu: Can this be done from the inventory buffer, if you mark the > > wanted files? > > If so: We should provide at least a good docstring to tell about that > > feature. > > Yes, I've added this in the patch > > [EMAIL PROTECTED] > Selected files commit from inventory > Matthieu Moy <[EMAIL PROTECTED]> > 2004-05-06 20:44:18 GMT > > 'm' to mark files, 'c' to edit the log file (this remembers which > buffer you're comming from), and C-c C-c will commit with the list of > files selected in the buffer at time of commit. > > This is also possible from the *tla-changes* buffer. Excellent! > >> 3) A way to specify that you want do automaticly generate a cacherev > >> every X revisions. > > > > We could add the information to the bookmarks file. What do the others > > think? > > Isn't that better done in ~/.arch-params/hook ? Yes you are right. This should be done there. > The problem of doing that from xtla is that you may want to commit > from the command line also from time to time. > > Specifying this in the bookmark file is problematic since this is > usually an information that should be archive-wide, and although > bookmarks can be set for an archive, you usually don't want to do so > to avoid pollution of the *tla-bookmarks* buffer. > > Don't know what the best solution is exactly. > > >> 4) Some like file-diff-rev from the aba which gives you the changes to a > >> file between two specified revisions using the following: > >> > >> diff -u $(tla file-find file.cpp $(tla > >> tree-version)--patch-X) $(tla file-find file.cpp $(tla > >> tree-version)--patch-Y) > > > > A nice idea. I have put it on the todo list. > > We already have tla-file-ediff (C-x T e, or just e in a *tla-changes* > buffer), and tla-revision-delta (in *tla-revisions*, mark a revision > with 'm', move your cursor to another revision, and 'd' to view the > delta. > > What you suggest is an extension of this. What I'd like to be able to > do is to press 'e' in the *tla-changes* buffer obtained by a > tla-revision-delta. > > Well, almost all the code is there, the UI have to be done. [...] > -- > Matthieu >
signature.asc
Description: This is a digitally signed message part
