The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Monday, July 14, 2014

DVCS branches = sets++

It is a good idea to be able to identify "sets" of revisions. Both by predicate functions, and by tagging with names.

Branches are sets that automatically extend: when you do a checkin from a workspace with a parent set that is a branch, the checkin automatically gets added to the branch set.

This allows branches to converge and then diverge:

of course, a version can be tagged as being in multiple sets

similarly, a version can be tagged as being in multiple branches at the same time.

Two versions on different branches can merge, and the branches can be converged for a while.  But then later diverge.

This can be done on a file by file basis:  not just whole repo versions, but individual file versions.






file-sets - most meaningful when file-version-sets

named-file-sets => these are objects that can be versioned


set operations on named-file-sets

=> partial, union, difference

BTW, parse this as named--file-sets or named(file-sets)

Doesn't need to be named(file-sets).  Can be anonymous.  Perhaps better called (explicit(file-sets)

or identified(file-sets)


I have elsewhere figured out that

partial checkouts are easy,

while partial checkins correspond to creating a branch, at least temporarily, from which changes can be propagated to larger filesets.

Probably with some sort of nagging system:

Partial checkin doesn't automatically check into containing filesets,

but does automatically check into candidate filesets for enclosing branches.

This might be a good place to exploit file versioning as opposed to whole repo version - candidate-filesets or candidate-branches on a per file basis.

No comments: