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

Re: Two copies of buildcheck.sh?

From: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-02-14 19:51:54 CET

On Thu, Feb 14, 2002 at 11:49:20AM -0600, Ben Collins-Sussman wrote:
> > Rev 1209 supposedly moved buildcheck.sh to the build directory, but I
> > still have a top level buildcheck.sh, and svn insists it belongs
> > there. (I have build/buildcheck.sh too.) What gives?
>
> There should be only one. gstein did an 'svn mv' of the file from
> /trunk/ to /trunk/build/. You should have seen an 'add' and a
> 'delete' when you updated. If you didn't then something is very
> wrong. I wonder why you still have that entry on the top level...?

I thought it might have something to do with the conflict annotation
so I edited it out, but that didn't help. Then I edited out the
entire entry and deleted buildcheck.sh and
.svn/text-base/buildcheck.sh.svn-base, and now it isn't coming back
anymore when I do 'svn up'. But it's still very strange.

Unfortunately, the update logs have scrolled away.

> > [[ Why do these timestamps care about timezone? Shouldn't we just
> > force them to UTC and forget about it? And what's the use of
> > remembering the day of week? ]]
>
> That text string is just an invariant form of apr_time_t. We switch
> the two types back and forth.

The comment above svn_time_to_nts says that the goal is to encode all
the information in an apr_exploded_time_t, and it does succeed in
doing that. What I guess I'm saying is that for SVN's purposes I
don't see any point in recording the day of week, day of year, DST
flag, or GMT offset.

Hmm, looks like this has already come up - see the todo comments at
svn_time_from_nts.

zw

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006

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.