[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 2541 -

From: <cmpilato_at_collab.net>
Date: 2002-07-15 19:03:54 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> cmpilato@collab.net writes:
> > > - Even if we always prevent no-op commits, should the log code be
> > > sensitive to that assumption, or should it work anyway?
> >
> > By not seeing the no-op commit in your log -v, I don't think you're
> > missing too much. :-)
> Well, yes, but someone who notices a hole in their revision history is
> going to be rightly disturbed :-).
> So we either need to guarantee that there can't be no-ops, or make
> "svn log" able to show no-ops. I'm okay with choice #1, but note that
> our repository now has a hole in it, and our dumper and loader is
> going to have to somehow deal with this. Does every revision after
> the hole get decremented by 1? Yick.

The dump/load thing shouldn't be affected. Why would there be a hole?
A no-op revision still has interesting information (author, date, log)
that would be dumped and loaded just like any other revision.

> Maybe we should just make "svn log" able to show such revisions
> instead. It's certainly the easy way out.

I'd rather do this than impose arbitrary restrictions on
svn_fs_commit_txn. I still feel like we should make all our library
layers between the client binary and libsvn_fs attempt to disallow
no-op commits, but it certainly should *not* be ruled out at the
libsvn_fs level. And, if one slips through the cracks, it should not
be a burden to the rest of the functionality of Subversion (like `svn

Though I admit I don't know the right way to fix `svn log' in this

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 07:06:04 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.