Fossil SCM
(untitled)
6aeda5a5f3989f3…
· opened 13 years, 1 month ago
- Type
- Feature_Request
- Priority
- —
- Severity
- —
- Resolution
- Overcome_By_Events
- Subsystem
- —
- Created
- March 7, 2013 10:40 p.m.
-1
First of all, this Ticket was submitted as a Code_Defect so I took the liberty of marking it as Feature_Request (which better reflects this Ticket).
Secondly, although the request described is a convenience (and a point-and-click interface feels more comfortable than typing in), IMHO this would create more problems than it would solve. Add, delete and commit belong to the working copy and nowhere else, the repository (and everyone else) see none of what you do until a successfuly commit is accepted by the repository; whereas the ui stuff is done on the on the repository and don't affect your (or any other users on localhost or elsewhere) local copy until you checkout/update from the repository. (Problems I see: what happens when two users are working on the same version? what happens when you open a version on another working copy, do you get only the files of that version or also the added files? what happens when you force a close of a working copy and then open a new working copy, do you get the added-but-not-committed files or do they stay in a limbo?)
--[jbatista]
Comments (5)
-1
First of all, this Ticket was submitted as a Code_Defect so I took the liberty of marking it as Feature_Request (which better reflects this Ticket).
Secondly, although the request described is a convenience (and a point-and-click interface feels more comfortable than typing in), IMHO this would create more problems than it would solve. Add, delete and commit belong to the working copy and nowhere else, the repository (and everyone else) see none of what you do until a successfuly commit is accepted by the repository; whereas the ui stuff is done on the on the repository and don't affect your (or any other users on localhost or elsewhere) local copy until you checkout/update from the repository. (Problems I see: what happens when two users are working on the same version? what happens when you open a version on another working copy, do you get only the files of that version or also the added files? what happens when you force a close of a working copy and then open a new working copy, do you get the added-but-not-committed files or do they stay in a limbo?)
--[jbatista]
Sure, it is a "feature request".
I understand your point, and effectively, there are some restrictions/rights that are required to be properly managed. Possibly, only localhost user is to be allowed for such actions. Other restricting solutions could be imagined (administration configuration, checkin rights, etc).
I keep convinced that such facility would be very good point for new fossil users, and for everyday users not having to use the command line. Personnaly, I like it a lot.
I started some tests to implement it, and I am happy with these first results. Implementation best arrangement is not so easy, in particular the "commit" because of the mix of user interactions and functionnal checks and actions. However, it looks very feasible.
If others are interested in this, I would appreciate to spend more time on it. In such a case, I would also appreciate, some advices of fossil developpers for the best way to do it, in particular in regard to the commit function, and menu implementations.
Seems conflict access could be solved by checking the "g.localOpen" boolean, does'nt it?
Working on this subject, seems very useful. Check that other people requested this function on several blogs, and some others consider the absence of this function as a disadvantage of Fossil.
Hi,
look at the web code editor ticket [http://www.fossil-scm.org/fossil/tktview?name=ad98e8f665]
it seems to be the same problem with per-user staging area.
Job done. Patch proposal sent to drh 2 weeks ago, but no response yet.