On Sun, Oct 23, 2005 at 07:09:36PM -0400, Stuart D. Gathman wrote: > On Sun, 23 Oct 2005, Chris Shoemaker wrote: > > > Alternatively, for another breed of SCMs the model is: the > > repository is a project that has history, which happens to be > > represented by files. This distinction may (or may not?) seem subtle > > but it is HUGE. This is the whole concept of > > changesets/patchsets/commits-whatever. It lets the user view and > > operate atomically on "changesets" that affect many files. This is > > *SO* useful, that once you're used to it, not being able to do it just > > seems like wandering around in the dark with you hands tied behind > > your back. > > I thought this was the main point of SVN, and the motivation for > replacing CVS - that it has atomic changesets that affect many files.
Please see: http://subversion.tigris.org/faq.html#changesets for a rather biased, but not unhelpful answer. The frank answer is that there's a *fundamental* *architectural* difference between designs that use arrays of versioned trees and designs that use DAGs of changesets. I would dispute the "neither philosophy is better" part. FWIW, my take on the status of this debate is that it's basically over. The systems using changesets have proven far more useful, and made the versioned-trees approach seem ... well... backward. But, there are those who feel far more strongly, and are far better informed than I, who make the case far better that I could. I'd suggest googling around and reading the rantings of some of the designers of changeset-based systems, if you're interested in the debate. Here's a fun link to git's author's opinion on the matter: http://www.gelato.unsw.edu.au/archives/git/0504/0594.html I'm sure dredging LKML for BK flamefests would turn up similarly fun stuff. Have fun! -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
