The tree version idea maps quite well to the model that many text editors use: there is the previously recorded version of the tree, and the unsaved next version of the tree that you are currently working on. As most text editors don’t allow you to selectively save changes to a file, I don’t think the analogy fits the other states.

For working tree states, I think it helps to think of a hierarchy of states rather than a flat list. The most basic is “versioned vs. unversioned”, where only versioned files make it into the next version of the tree.

With this categorisation, “versioned” corresponds to your “index” state. I’d then add the subcategories of “unchanged”, “modified”, “added” and “deleted”. These subcategories are all relative to the previous tree versions.

Under “unversioned”, there are “ignored” and “unknown” (or limbo if you want). By definition, there is no information about unversioned files in previously tree versions.

John: Think outside of the box.

Greetz Mathias,
Awaiting insightful follow-ups.

Indeed, and I really appreciate your articles on the matter. Lot of people really miss use/understand VCS. The concept is not that easy to grasp for everyone. Keep on that really good series.

Thanks.

If you’re talking about the other posts, I’ve had feedback from other people that they were very useful to them in understanding the various systems. I guess my goals are just different than you seem to be assuming. I’m not trying to encourage convergence of the VCS market (sure it’d be nice, but I agree it won’t happen). And I don’t understand your comment that the VCS debate is a moot point, though I really wasn’t trying to get involved in a debate–I was trying to provide information useful for understanding various systems and help individuals compare and contrast them on their own.

Haven’t though in any positive way about the index first, but now the “git add && git commit” instead of a simple “svn commit” makes sence.