I see UseCase1 as a private branch in a local clone of an existing repository. The ability to only 'sync' the last in a series of commits back to the 'master' repository would be good.. perhaps by extending the new branch functionality to be able to flag a particular branch as --private ??? (and therefore excluded from all sync events unless explicitly requested)
UseCase2 is a little more interesting.. being able to selectively sync checkins between two copies of essentially the same repository is probably very useful, but i am struggling to get the syntax logic right in my head, so I can't really suggest any concrete examples.. perhaps it would be easier to keep it all in the same repository, but force certain branches to require extra permissions??? so public checkins could be kept in a '-public' branch, and only certain users could merge them with the true 'truck' branch???? (i suspect managing the permissions on such a repository and having to explain it to Joe Public could get *really* difficult, so this may not be such a useful idea) I do, however, have a 3rd UseCase for multiple repositories that i think is a much simpler problem.. I have developed my own web library/framework that is the basis of multiple projects. I keep the code for the individual websites I build in a different repository than the shared framework code, however to test them, i really need them to be in the same root folder.. so the ability to check out multiple repositories in to the same folder would be a HUGE bonus for my workflow.. Let me be more verbose.. I have a core Project A that has a set of files and folders.. - index.php - lib/db.php - lib/form.php - etc... I have projects B,C & D that have their own set of files and folders.. - config.php - res/site.css - res/logo.gif - res/user.db - etc... but I also need a copy of project A to be included in each of these projects to be able to test and/or release them, so I need to be able to do the following.. - chdir to //dev/www/projC/ - open projA.fossil - open projC.fossil and end up with a combination of both sets of files.. I don't think this is particularly difficult to implement (in my VERY limited understanding of how fossil works) since the files for each project are essentially just "extra" files for the other project.. as long as I can specify which repository I mean when I am "adding" a file, then it all should just work. I would suggest that if multiple repositories are checked out in the same folder that any ADD, RM, UPDATE etc should be forced to specify the repository to use as its source.. either provide an error or perhaps even a prompt in the CLI??? ie "Multiple Repositories found, use [1,2,3]" etc.. At the moment, I am manually copying ProjectA's files into each of the other folders whenever I do an update, but that is starting to be very tedious.. Let me know if I need to explain myself further.. regards Daniel D. Richard Hipp wrote: > 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 > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
