I like the new branching changes, they fit in very nicely (with my view of the subject :-) , but also into the internal workings of fossil with surprisingly little disruption).
Anyway, here are my thoughts on the next bit... > I'm looking to extend the command-line interface of fossil to handle two new use cases. But I would like advice from the community on what the user interface for these features should look like. If you have a chance, please read over what I am trying to accomplish and suggest ways of structuring the CLI interface. > OVERVIEW > In the current fossil design, an open check-out is only associated with a single fossil repository. When you do "fossil open" that creates your local check-out and associates it with one particular local repository and no other. I would like to extend this to allow an open check-out to be associated with two or more repositories. > USE CASE 1: Private Branches > Suppose there is a high-visibility public project bigproj.fossil. Alice has a local clone of bigproj.fossil and has a local check-out of the sources. She want's to contribute. But she always wants to experiment privately before committing all of her changes for the world to see. She would like a private branch. > To do this, Alice runs a command > ??What should this command be?? fossil isolate ?--force? private.fossil (don't overwrite an existing file unless told its OK) > that creates a new private fossil repository named private.fossil that contains as its sole check-in a snapshot of the version of > bigproj.fossil Alice was previously looking at. The check-out is left connected to private.fossil. Alice then makes various edits, > committing periodically to private.fossil. After a while, Alice decides her changes ready for public consumption, so she switches her check-out back over to the bigproj.fossil repository using command: > ??What should this command be?? fossil rejoin That's all, the name and checkout information for bigproj.fossil have been remembered in _FOSSIL_ or somewhere. > Then she commits and pushes. All the other users of bigproj.fossil only see that one last commit. The interim commits that Alice did to private.fossil stay in private.fossil and are not publicly visible. Only the final commit to bigproj.fossil gets published. If Alice is taking a while to get her changes done, she might want fossil catchup which switches back to bigproj.fossil, syncs it (maybe?), does an update, and switches to private.fossil again, leaving Alice to sort out any merge issues before she continues with her changes. The current checkout info for bigproj.fossil will now refer to the checkout updated to. This is equivalent to someone working on a normal branch and merging the trunk into it from time to time. If, when Alice does fossil rejoin this is really only phase one, and she wants to go on working on phase two, she can follow the rejoin with. fossil isolate (no arguments) with the result of the rejoin + isolate being, except for the fact that there is probably a checkin to bigproj.fossil in the middle, exactly like a catchup. I'm sure there are issues which will require various optional bits on these commands. > USE CASE 2: Repository of Reviewed Code This one seems to have a lot more possible complications, and I probably need to think about it some more, so all I have for now is the obvious (to me) command names. > Suppose project wide.fossil contains dozens or hundreds of > contributors, some of which are untrustworthy. It is desired to have a separate trusted.fossil repository that contains only those check- ins to wide.fossil that have been reviewed by the one or two trusted contributors, to make sure they do not violate design rules or > introduce trojans, etc. > Bob is one of the trusted contributors. He has local clones of both wide.fossil and trusted.fossil. He first opens wide.fossil and looks at a particular leaf of that tree. After careful review, he decides that leaf is suitable for import into the trusted.fossil repository. So he commits his current check-out (which was obtained from > wide.fossil) into the trusted.fossil repository using this command: > ??What should this command be?? fossil accept > The previous command left Bob's local check-out connected to > trusted.fossil. ??Or should it leave him connected to wide.fossil?? Bob can either leave his check-out connected as is and continue to work in the repository where he was left, or he can connect to the other repository using this command: > ??What should this command be?? fossil review I suspect that some alternate names might have to be supported if there are use cases that are functionally the same, but different in intent. > SUMMARY > I think the idea of being able to commit a check-out obtained from one repository into another repository can give fossil some powerful new features - features that people need and want. But I'm unclear on exactly what the interface should look like. Please offer your > suggestions. If you have other ideas for use cases where a single check-out might be associated with multiple repositories, please let me know. USE CASE E3: Code shared between projects. This is about genuinely shared/reused source, not common-use libraries which should probably be kept separate. A checkout could be connected to two (or more) repositories at the same time, and it could be totally transparent except if you try to create a clashing filename AND when committing. A commit can be to all the repositories, or only some of them. For the repositories that are missed, any changed files remain in the changed state. Which is probably quite enough for one night :) Regards, Eric _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
