On Oct 5, 2006, at 6:48 PM, Frank Cusack wrote:
On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet <[EMAIL PROTECTED]
b.net> wrote:
Well, unless you have a better VCS than CVS or SVN. I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment. And I used one commercial product (written by an NSE
user after NSE was discontinued) that supported the feature needed.
Both of these had what I might call a two-level VCS. Each developer
had one or more private repositories (the way people have working
directories now with SVN), but you had full VCS checkin/checkout (and
compare and rollback and so forth) within that. Then, when your code
was ready for the repository, you did a "commit" step that pushed it
up from your private repository to the public repository.
I wouldn't call that 2-level, it's simply branching, and all VCS/SCM
systems have this, even rcs. Some expose all changes in the private
branch to everyone (modulo protection mechanisms), some only expose
changes
that are "put back" (to use Sun teamware terminology).
Both CVS and SVN have this.
-frank
David is describing a different behavior. Even a branch is still
ultimately on the single,
master server with CVS, SVN, and more other versioning systems.
Teamware, and a few
other versioning systems, let you have more arbitrary parent and
child relationships.
In Teamware, you can create a project gate, have a variety of people
check code into this
project gate, and do all of this without ever touching the parent
gate. When the
project is done, you then checkin the changes to the project gate's
parent.
The gate parent may itself be a child of some other gate, making the
above
project gate a grand-child of some higher gate. You can also change a
child's parent,
so you could in fact skip the parent and go straight to the "grand"
parent if you wish.
For that matter, you can re-parent the "parent" to sync with the
former child if you
had some reason to do so.
A Teamware putback really isn't a matter of exposure. Until you do a
putback to the
parent, the code is not physically (or even logically) present in the
parent.
Teamware's biggest drawbacks are a lack of change sets (like how
Subversion tracks
simultaneous, individual changes as a group) and that it only runs
via file access
(no network protocol, filesystem or NFS only.)
Mercurial seems to be similar to Teamware in terms of parenting, but
with network protocol
support builtin. Which is presumably OpenSolaris will be using it.
ckl
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
