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

Re: svn failing commit messages.

From: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2003-01-13 11:25:54 CET

On Sun, Jan 12, 2003 at 11:09:45PM -0600, Karl Fogel wrote:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > We deliberately don't write them to /tmp, because we want them a) to
> > be easy to find, and b) not likely to get caught up in the automated
> > cleaning sweeps that some systems run on /tmp. The principle is "Use
> > /tmp, or some other system-defined tmp area, for data generated by
> > Subversion; but use the current directory for data generated by a
> > human", the rationale being that data generated by a human could be
> > arbitrarily costly to regenerate.
> Oooh -- cmpilato's later followup reminded me that we do indeed use
> .svn/tmp (when available) for human-generated files, since it's not
> subject to automated sweeps, and is relatively "nearby".
> Nevertheless, in the import case, there is no such dir, so we fall
> back to the current dir... Hey!
> We could *make* a .svn/ dir and then put the file in .svn/tmp. When
> we create the file at all, we're already violating (in a small way)
> the rule that import should leave the source data unaffected. At
> least by making a .svn dir, we don't risk importing the tmp file if a
> second import attempt is made.
> Thoughts?
Not apart from the (already present) problem that someday I'd like to be able
to import data from a read-only medium like a cd-rom.

Maybe we should move commit messages to ~/.subversion/ instead of current
directory. Then we would be able to leave the file around, and still be able
to have a read-only source dir.

Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall

  • application/pgp-signature attachment: stored
Received on Mon Jan 13 18:27:39 2003

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.