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