On Mon, Oct 24, 2005 at 12:38:35PM -0400, Stuart D. Gathman wrote: > On Sun, 23 Oct 2005, Chris Shoemaker wrote: > > > > 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. > > Thanks. That was very helpful. So SVN does have atomic commits > that affect multiple files - unlike CVS. But it internally stores versioned > trees of file collections vs versioned trees of files for CVS vs > collections of patches for changeset based systems.
If you'd like some more detailed info, I'd recommend: [5] for the heart of the issue in concise terms [6] for an good overview of the main SCM debate [8] for an overview of SCM softwares available [1, 2, 7] for some informative Arch vs. SVN debate [3] for a practical perspective on SCM usage [1] http://www.reverberate.org/computers/ArchAndSVN.html [2] http://web.mit.edu/ghudson/thoughts/undiagnosing [3] http://www.kdedevelopers.org/node/1028 [4] http://subversion.tigris.org/faq.html#changesets [5] http://sourcefrog.net/weblog/software/vc/derivatives.html [6] http://www.dwheeler.com/essays/scm.html [7] http://web.mit.edu/ghudson/thoughts/diagnosing [8] http://linuxmafia.com/faq/Apps/scm.html > > > 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. > > A very important feature for me is that the repository format stills allows > me to extract the latest version of things if it gets corrupted. I'm > not sure SVN meets that criterion, but CVS does. That was the main > motivation for us moving from SCCS to RCS before CVS came out. before CVS came out?! You've .. um... been around a while, eh? :) > > > 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. > > I can easily see how certain operations would be quicker and more > natural for a changeset system. But there are many criterion, and > I suspect said rantings reflect different priorities than mine. > > > 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 > > The main point here is that per file tracking is wrong - and I would > agree. Maybe I'm missing something, but from what I have read, SVN > stores version trees of filesets rather than files - that is its motivation > for > replacing CVS. Sure, it is storing version trees of the fileset rather > than a collection of changesets for the fileset, but the above rant doesn't > seem to apply to SVN. You might agree or disagree with the premise but the rant *certainly* applies to SVN. The links above will explain. -chris > > -- > Stuart D. Gathman <[EMAIL PROTECTED]> > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 > "Confutatis maledictis, flamis acribus addictis" - background song for > a Microsoft sponsored "Where do you want to go from here?" commercial. > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel