Hi Richard,
On Mon, 26 Jan 2009 10:21:27 -0500, you wrote:
[nice proze]
>USE CASE 1: Private Branches
>
>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??
fork ?--repository|-R bigproj.fossil? \
--to|-T private{N}.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??
release ?--repository|-R private.fossil? \
--to|-T bigproj.fossil
>Then she commits and pushes.
Couldn't the switch back be combined with the commit?
At first sight it is the same as USE CASE 2, where Bob
commits the checkout from wide.fossil into trusted.fossil.
Hm, the difference between the two might be that Alice's
work should show up as one commit, while Bob's commit would
show all commits that where found in wide.fossil.
If so, USE CASE 1 is a commit, but to another (bigproj) than
the current (private) repository, and the command could be:
commit --to|-T bigproj.fossil --comment|-m COMMENT-TEXT
Leaving Alice with bigproj.fossil as the current repository,
which should be expressed by a proper fossil message or even
a status report. Because it is easy to forget which of the
private{N}.fossil repositories is current, it might be wise
to ask for user confirmation for the current checkout.
(And a -Q|--quiet option to suppress the confirmation, just
in case someone would write a smart wrapper).
And we need something else than commit for USE CASE 2.
> 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.
A very useful feature indeed.
>USE CASE 2: Repository of Reviewed Code
>
> 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??
commit --to|-T trusted.fossil --comment|-m COMMENT-TEXT
would not do, assuming the wide.fossil repository itself is
needed to copy all intermediate commit properties from
wide.fossil into trusted.fossil.
So I propose:
accept --to|-T trusted.fossil ?--comment|-m COMMENT-TEXT?
>The previous command left Bob's local check-out connected to
>trusted.fossil. ??Or should it leave him connected to wide.fossil??
He's done reviewing wide.fossil, so it should leave him
connected with trusted.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??
Assuming there could be more than one wide.fossil, it would
be necessary to use it's name explicitly.
switch -T|to wide{N}.fossil
or simply
checkout --repository|-R wide{N}.fossil
I'm not very proficient with repositories, so please don't
overestimate the value of my contribution.
>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.
I agree.
> But I'm unclear on exactly what the interface should look like.
It's a tough one indeed.
> 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.
I always struggle with common code trees shared by more than
one project, for example, sqlite being used by itself (i.e.
the CLI tool), in fossil and some other projects. Or common
shell scripts used to prepare a well known environment
(PATH, constants, etc), wich can be used by several
projects. Of course it is possible to maintain it in a
separate repository, but it seems nicer to include it in
each project repository that needs that common code.
A somewhat different problem than the feature you propose
here. And there's an easy work around, usually I simply
duplicate code. Or I could make hardlinks (seems to be even
possible in Windows/NTFS).
Handling all this functionality isn't always easy, people
easily lose track of what they were doing.
It would be slightly more than "nice to have" to store the
recent command history (only modifications) in the users'
~/.fossil | %USERPROFILE%\AppData\Local\_fossil database.
The SUN zfs filesystem does that (even full history from
creation to current status), and it proves helpful debugging
ones own, and other peoples, mistakes when they get stuck.
That feature implies two more commands:
fossil history ?--count|-n N?
History of all repositories associated with the current
checkout.
fossil all history ?--count|-n N?
History of all repositories.
>Thanks for your attention.
Thanks for your inspiring ideas.
>D. Richard Hipp
>[email protected]
--
( Kees Nuyt
)
c[_]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
