file date in the repository

[MD...@medistar.de]

Hello,

my problem is to either import files in to the repository with the dates of
the files intact or change the svn:date later.

Since I found no way to import the files with the date intact, I thougth
that I could use the command 'svn propset svn:date ...' to modify the date
in the repository.  This seemd to work fine.  But now, when I try to verify
the repository is get the error message 'svn: Bogus date' on 'old revisions.
My suspicion is that this was caused by my actions.

Can someone confirm this and/or tell me how I can get the files date in to
the repository?

Thanks, Michael

Re: file date in the repository

[Marius Gedminas <mg...@b4net.lt>]

On Tue, Jan 18, 2005 at 11:51:05AM -0500, Scott Palmer wrote:
<snip two-world timestamp preservation theory>
> So back to the point, is there any reason that Subversion should 
> support both worlds?

Someone seems to be working on it:

  http://subversion.tigris.org/issues/show_bug.cgi?id=1256

Marius Gedminas
-- 
Some people around here wouldn't recognize
subtlety if it hit them on the head.

Re: file date in the repository

[Scott Palmer <sc...@digital-rapids.com>]

On Jan 18, 2005, at 10:53 AM, Dale Worley wrote:

> -----Original Message-----
> From: Scott Palmer [mailto:scott.palmer@2connected.org]
>
> claiming (with an amazing bit of ridiculous
> circular reasoning) that timestamps shouldn't be relied on because some
> things don't preserve them, so Subversion isn't going to preserve them.
> ---------------------------------------------------------------------
>
> More exactly, they live in a world where *many* things don't preserve
> timestamps, so nobody writes tools that rely on them.  In that 
> environment,
> getting Subversion to preserve timestamps gains the users little, 
> because no
> tool depends on them.  And if Subversion preserved timestamps, still 
> nobody
> would write tools that depended on them.
>
> But there is another world -- a world where most tools preserve 
> timestamps.
> And many tools depend on them.  And you live in that world.

I guess it is true, I don't encounter many things that don't preserve 
timestamps.  Other than the tools that modify the file in the first 
place, I copy the file from one place to another and the timestamp goes 
with it in all the cases that matter to me.  Losing a timestamp is the 
exception to the rule.

So back to the point, is there any reason that Subversion should 
support both worlds?   I don't think anyone on the side of preserving 
timestamps is arguing against the fact that intentionally changing the 
timestamp has merit in many cases, such as not breaking 'make'.   But 
that is quite clearly an intentional munging of the timestamp metadata 
for a particular purpose.

It seems clear to me that "things that don't preserve timestamps" cause 
a problem that results in "nobody writes tools that rely on them".  
Given that the entire reason for not writing tools that rely on 
timestamps  is because other tools messed up and didn't preserve them 
(which is sort of funny here, because one of the major arguments for 
modifying the timestamp is to be compatible with a tool, namely 'make', 
specifically because it relies on timestamps), it seems only logical 
that now that the problem is recognized the mistake would be avoided.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: file date in the repository

[Dale Worley <dw...@pingtel.com>]

-----Original Message-----
From: Scott Palmer [mailto:scott.palmer@2connected.org]

claiming (with an amazing bit of ridiculous
circular reasoning) that timestamps shouldn't be relied on because some
things don't preserve them, so Subversion isn't going to preserve them.
---------------------------------------------------------------------

More exactly, they live in a world where *many* things don't preserve
timestamps, so nobody writes tools that rely on them.  In that environment,
getting Subversion to preserve timestamps gains the users little, because no
tool depends on them.  And if Subversion preserved timestamps, still nobody
would write tools that depended on them.

But there is another world -- a world where most tools preserve timestamps.
And many tools depend on them.  And you live in that world.

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: file date in the repository

[Scott Palmer <sc...@2connected.org>]

On Jan 17, 2005, at 5:09 PM, Marius Gedminas wrote:

> Hi,
>
> On Mon, Jan 17, 2005 at 10:24:52PM +0100, Peter Valdemar Mørch wrote:
>>
>> There have been numerous threads about this in the past. The "winning
>> side"'s argument is that newly checked out files need to be 
>> timestamped
>> "now" regardless of when they really were created, because otherwise
>> make systems (the assumed most common usage) get confused. The 
>> "loosing
>> side"'s arguments, well, who can remember them? :-D

I've argued the point before, as have several others.  I don't recall 
'losing' as much as the Subversion developer's simply wouldn't 
acknowledge the point - claiming (with an amazing bit of ridiculous 
circular reasoning) that timestamps shouldn't be relied on because some 
things don't preserve them, so Subversion isn't going to preserve them.

> There's also
>
>   [miscellany]
>   ### Set use-commit-times to make checkout/update/switch/revert
>   ### put last-committed timestamps on every file touched.
>   use-commit-times = yes
>
> in ~/.subversion/config
>
> And it does confuse make, as I've had the chance to discover today. ;-)
>

I find it odd that the argument against preserving important meta data 
comes down to the fact that a build tool such as make can get confused, 
so everyone must suffer to make up for it.  A simple option to preserve 
the timestamp using a property much like svn:executable makes sense.   
Btw, sv:executable seems to always do the wrong thing on Windows which 
doesn't have an executable property in the native file system resulting 
in svn:executable being set for every file.

The lack of this feature seems short sighted..  For similar reasons as 
'make' needs to have the timestamp bumped, other tools might want it 
preserved. There is a reason that all modern filesystems store such 
meta data!  You implemented preserving of the 'executable' property 
that isn't even stored by some of the filesystems that Subversion runs 
on.  Surely there is some justification for preserving properties that 
are common to all the filesystems.

Is there an existing feature request for something along the lines of 
svn:date or svn:modtime?

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: file date in the repository

[Marius Gedminas <mg...@b4net.lt>]

Hi,

On Mon, Jan 17, 2005 at 10:24:52PM +0100, Peter Valdemar Mørch wrote:
> MDidschuns@medistar.de wrote:
> >Can someone confirm this and/or tell me how I can get the files date in 
> >to the repository?
> 
> I'm not sure what you're trying to accomplish, but I believe the client 
> will always modify the date of flies when checking them out to be the 
> current date/time, regardless of the date it had when checked in.
> 
> There have been numerous threads about this in the past. The "winning 
> side"'s argument is that newly checked out files need to be timestamped 
> "now" regardless of when they really were created, because otherwise 
> make systems (the assumed most common usage) get confused. The "loosing 
> side"'s arguments, well, who can remember them? :-D
> 
> So if you are trying to get a checked out file to have the same date as 
> when it got checked in, I think you may be fighting a loosing battle here...

There's also

  [miscellany]
  ### Set use-commit-times to make checkout/update/switch/revert
  ### put last-committed timestamps on every file touched.
  use-commit-times = yes

in ~/.subversion/config

And it does confuse make, as I've had the chance to discover today. ;-)

Marius Gedminas
-- 
We've found by experience that people who are careless and sloppy writers are
usually also careless and sloppy thinkers (often enough to bet on, anyway).
	-- ESR (http://www.tuxedo.org/~esr/faqs/smart-questions.html)

Re: file date in the repository

[Peter Valdemar Mørch <no...@morch.com>]

Hi there,

MDidschuns@medistar.de wrote:
> Can someone confirm this and/or tell me how I can get the files date in 
> to the repository?

I'm not sure what you're trying to accomplish, but I believe the client 
will always modify the date of flies when checking them out to be the 
current date/time, regardless of the date it had when checked in.

There have been numerous threads about this in the past. The "winning 
side"'s argument is that newly checked out files need to be timestamped 
"now" regardless of when they really were created, because otherwise 
make systems (the assumed most common usage) get confused. The "loosing 
side"'s arguments, well, who can remember them? :-D

So if you are trying to get a checked out file to have the same date as 
when it got checked in, I think you may be fighting a loosing battle here...

I'm not sure what to search for, but there have been threads in the past 
about this. (If that is what you're trying to do.)

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org