----- Original Message -----
From: "D. Richard Hipp" <[email protected]>
To: fossil-users <[email protected]>
Subject: [fossil-users] User interface design questions
Date: Mon, 26 Jan 2009 10:21:27 -0500
[snip]
>USE CASE 1: Private Branches
I'd do this by-hand by
1. Copying the checkout, (or some version of it)
to a new directory, and deleting the _FOSSIL_
file.
2. Creating a new repo, and adding everything in
the copy of the checkout to it (and Thank You
Again for recursive add!)
To put the changes back into the main branch,
1. Copy the "private" checkout over the main
checkout.
2. Do an 'extra' and find what needed to be
added, and add it.
3. Check it in, tag it and push it.
Would the private repository interface produce results
distinguishable from the above (apart from being a lot
easier on the dev) _after_ the merge back to the trunk?
USE CASE 2 is a very similar thing, when you look at doing
it "by hand". In that case, you have devs who grab things
from a widely publicized and easy-to-be-part-of repo and
shove them into a secret-not-publicized repo.
>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
Ok, I think we just left Kansas (but only went as far as
Nebraska. Heh.) What you're describing here is a little
bit different than the use cases. This is sort of the
general case and really matches my DiY examples.
I'm thinking that, before the interface can be decided you
really need to figure out _what is going to relate the
different checkouts_ in both of the use cases. In the DiY
examples it's the developers intentions and any agreed on
protocols. It seems to me that an interface for either
scenario should gain something, probably better integrity
and maybe security.
But if the basic idea in both cases is having some sort of
meta-master repo that holds the Platonic Ideal Versions,
while the master repo holds the Imperfect Real Versions,
you can combine the two, and you have a chain:
private copy->local master->public master->meta-master
If that's the case, you could sort of "upvar" the commits
when you wanted to go a level higher; maybe with an --up
option to fossil commit.
<Thud />
Ow. Well, I was going to add more, but I fell off my high
horse. Oh well.
--kkinnell
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
