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.



--



repo-versions

repo-version-sets



file-versions

file-version-sets



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



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



named-file-set-versions



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.