[Xcb] SCMS for XCB?

[Barton C Massey]

I'm just not sure I can wait that long. 1/2 :-)

	Bart

In message <1122904202.18154.11.camel at localhost.localdomain> you wrote:
> I think almost everyone working on X would like a new SCM.
> 
> But which one isn't yet quite clear.
> 
> I expect this will become a serious topic of discussion this fall after
> the modular release ships.
> 			Regards,
> 				- Jim
> 
> 
> On Mon, 2005-08-01 at 09:18 -0400, Trevor Woerner wrote:
> > On Saturday 30 July 2005 14:46, Barton C Massey wrote:
> > > In message <200507301430.31666.xcb506 at vtnet.ca> you wrote:
> > > > On Saturday 30 July 2005 13:34, Barton C Massey wrote:
> > > > > Also, is a reasonable ASCII repository format a
> > > > > requirement?
> > > >
> > > > Subversion has had support for both ASCII (fsfs) and binary
> > > > (Berkley-db) repository formats for a while. Whoever sets up the
> > > > repository has always had a choice, although db has been the
> > > > default. With the latest release of subversion, 1.2.0, fsfs (i.e.
> > > > ASCII) is now the default.
> > >
> > > AFAIK, fsfs is still a binary format.  Am I confused?
> > 
> > fsfs stores each revision and each revision's properties as a separate 
> > file (0, 1, 2, ...). You can work with these separate files as you 
> > would any other file in the system. My understanding is that these 
> > files are stored in something called "delta-storage" which means you 
> > can open them with a text editor, basically get the gist of what's 
> > going on (you can [mostly] "read" them), but don't make any 
> > modifications because the meta-information will now be wrong. Btw, the 
> > meta information appears to be stored in ASCII.
> > 
> > The bdb (Berkley DB) backend stored the entire repository into one 
> > binary database file. Special tools were needed in order to examine any 
> > internals.
> > 
> > Is that considered ASCII format? I don't know if this would qualify for 
> > you. Just because you can read the file doesn't mean it should be 
> > modified (in fact it shouldn't be). There is a process for changing a 
> > log message after a commit (say, to fix spelling). But usually after a 
> > commit has occurred the database shouldn't be touched.
> > 
> > I guess we've ended up in this funny state: basic usage of CVS required 
> > us to be able to muck around in the repository internals because of all 
> > of CVS's shortcomings. Now we've come to expect to be able to muck 
> > around in the guts of a repository and made it a requirement. But 
> > hopefully if the SCM works well this won't be required. :-)
> > 
> > Here's a URL to a document from the creators of subversion plainly and 
> > honestly comparing the fsfs backend to the bdb backend:
> > http://svn.collab.net/repos/svn/trunk/notes/fsfs
> > 
> > Maybe browsing through subversion's FAQ might be of interest:
> > http://subversion.tigris.org/faq.html
> > 
> > As an example, here at home I have but one project under subversion 
> > revision control. So far I only have 5 commits. Running "file" on each 
> > of the database files gives:
> > 
> > [trevor at osmium revprops]$ file *
> > 0: ASCII text
> > 1: ASCII text
> > 2: ASCII text
> > 3: ASCII text
> > 4: ASCII English text
> > 
> > [trevor at osmium revs]$ file *
> > 0: ASCII text
> > 1: ASCII text
> > 2: data
> > 3: ASCII text
> > 4: data
> > 
> > Why did revisions 2 and 4 of the revisions come up as data (i.e. 
> > binary)? Because I committed binary files in those transactions (some 
> > png images in 2 and a pre-compiled binary in 4).
> > _______________________________________________
> > xcb mailing list
> > xcb at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xcb
> 
> _______________________________________________
> xcb mailing list
> xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb