Re: timestamp preservation design (issue 1256)

Greg Hudson <ghudson@MIT.EDU> writes:

> On Tue, 2003-06-24 at 12:52, Ben Collins-Sussman wrote:
> > Greg Hudson <ghudson@MIT.EDU> writes:
> >
> > > On Tue, 2003-06-24 at 10:46, Ben Collins-Sussman wrote:
> > > > I think I'm starting to agree with Justin, and Karl is too.
> > >
> > > Ew, no, no, no, no, no. -1 on the CVS behavior.
> > >
> > > It's surprising,
> >
> > To whom?
>
> It was highly surprising to me when I found out about it as a CVS user.

Heh, that's funny. So I'm saying that "but CVS users are used to it",
and you're saying "but that doesn't mean it isn't weird". :-)

> > For developers, it *does* satisfy make 90% of the time.
>
> If you're going to do something truly awful in order to make something
> else work, it should be a 100% solution, not a 90% solution.

OK, well, let's try a small variation (from kfogel). What if our
behavior were this:

   * checkouts and updates always use the commit-time

   * updates always use the 'now' time.

This allows 'make' to work no matter what, even if you do unusual wc
backdating that involves deletes & adds. Is that a 100% solution?

If so, it would also make my hypothetical release managers happy as
well. And it would be just as trivial a libsvn_wc change.

> > Maybe I should say: "managers". Managers check out whole tags. They
> > don't keep working-copies lying around. They check out a tree, build
> > it, then delete the tree. Same goes for automated build-systems.
>
> I'm a release manager (in my work capacity). It takes hours to check
> out my 1.6GB source tree. I keep one lying around, and so does my
> automated build system.

Yeah, I'm on crack, never mind. I was thinking about "release
managers who create tarballs via 'svn export'".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 21:16:05 2003