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??
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??
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.
USE CASE 2: Repository of Reviewed Code
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??
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??
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.
Thanks for your attention.
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
