Fwd: Feature request: Keep file dates

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

At Ben's prompting I would like to discuss issue # 1256 - Having the 
ability to maintain the exact modified date/times for files when they 
are checked in and out off a Subversion repository.

I don't particularly like the proposed property name "svn:text-time", 
since I want this feature mainly for non-text files.  But it on looking 
at the patch (I'm NOT familiar with any of the subversion code) it 
seems that 'text' is referring to the file data, as opposed to the 
subversion properties set on the file. (e.g. 'text' changes are changes 
to the data content of the versioned resource, 'prop' changes are 
changes to subversions metadata (versioned properties) for the 
resource.  Right?

Related to the above, I also think it is important that this can be 
configured on a file-by-file basis.. I might want source code to work 
the usual way, but image files to retain their modification time, for 
example.

Here's an excerpt from the the thread that prompted my post...
(Btw.. Why does 'previous in thread' often fail to go to the correct 
message when viewing the list archives?)
(thread begins here: 
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=92595)

Begin forwarded message:

> From: Ben Collins-Sussman <su...@collab.net>
> Date: February 22, 2005 11:36:49 AM EST
> To: Scott Palmer <sc...@2connected.org>
> Cc: "'subversion' Users" <us...@subversion.tigris.org>
> Subject: Re: Feature request: Keep file dates
>
>
> On Feb 22, 2005, at 10:22 AM, Scott Palmer wrote:
>>
>> The use-case that comes up here is for .pdf files or other content 
>> generated by non-programmers who do not directly use subversion.  
>> They hand a file over to the engineering team to incorporate into a 
>> build.  On their own computers they have their own organization of 
>> the files and talk in terms of when they last updated the file, not 
>> when the engineering team decided to commit it to subversion.  When I 
>> have to answer something along the lines of, "Did you get the changes 
>> I made last Thursday?"  I can't go by the commit time that shows the 
>> following Monday because that isn't a strong enough indicator that I 
>> have Thursday's changes.  Maybe I got an update on Wednesday and 
>> that's what I committed.  If the timestamp (and size, etc.) matched 
>> exactly with the file that the creator has, I'm pretty confident that 
>> we are talking about the same thing.
>
> Wow, that's really clear.  Thanks for that explanation and example.  
> Maybe you should come persuade folks over on dev@ to increase the 
> priority and work out the implementation of this feature.
>
> There's already an issue #1256 patch, but it needs a lot more 
> attention and discussion.  (I'm tied up working on the locking feature 
> right now.)

Re: Fwd: Feature request: Keep file dates

["Ph. Marek" <ph...@bmlv.gv.at>]

On Wednesday 23 February 2005 17:45, Scott Palmer wrote:
> At Ben's prompting I would like to discuss issue # 1256 - Having the
> ability to maintain the exact modified date/times for files when they
> are checked in and out off a Subversion repository.
>
> I don't particularly like the proposed property name "svn:text-time",
> since I want this feature mainly for non-text files.  But it on looking
> at the patch (I'm NOT familiar with any of the subversion code) it
> seems that 'text' is referring to the file data, as opposed to the
> subversion properties set on the file. (e.g. 'text' changes are changes
> to the data content of the versioned resource, 'prop' changes are
> changes to subversions metadata (versioned properties) for the
> resource.  Right?
I named it this way because the ".svn/entries"-file had "text-time" as the 
property name, and I simple prepended "svn:" to take the _internal_ 
namespace.

I'd beg to keep the property names as they are now; we've been too long in 
production with these names.


> Related to the above, I also think it is important that this can be
> configured on a file-by-file basis.. I might want source code to work
> the usual way, but image files to retain their modification time, for
> example.
This is possible; either setting this property manually or by auto-props.


Mostly as a proof-of-concept I've started another way to implement *dynamic* 
properties.
This time by checking in svn_wc__load_prop_file() if we load the wc-props, and 
if this is the case, injecting the *real* values in the hash (for all already 
existing properties svn:text-time, svn:owner, svn:group, svn:unix-mode).
Similarly when setting properties via svn_wc__save_prop_file().

I've got to check the behaviour and to fix some things (using the timestamp of 
the property files is not enough to decide if they're unchanged), and that 
will take some time.

Possibly this will be a "cleaner" way to do these things - treating the 
meta-data as properties directly. Therefore the behaviour for update and 
conflicts are defined.


Setting these property values (and using them on checkout, update etc.) via a 
wrapper (as suggested by eg. Branko) is not a clean way IMHO as 
- first the changed files have to be found (with respect to -N, -R, etc.)
- the values have to be set
- and then the commit process must run once again over the files.

Furthermore I see it as a important aspect that as much as possible of the 
data (and I count meta-data too) is saved.
If there's too much stored I'll need some extra space, but if there's 
something missing it can't be reconstructed later.

And btw, I see usage for subversion beyond "simple" source version management.


Regards,

Phil



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

Re: Feature request: Keep file dates

[Travis P <sv...@castle.fastmail.fm>]

On Feb 23, 2005, at 10:45 AM, Scott Palmer wrote:

> (Btw.. Why does 'previous in thread' often fail to go to the correct 
> message when viewing the list archives?)
> (thread begins here: 
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=92595)

Heh, because the tigris archives are rather broken.

Mentioned on http://subversion.tigris.org/mailing-list-guidelines.html:
   A mirror of the mailing list archives, with a somewhat different 
interface, is at http://svn.haxx.se/users (for users@), and 
http://svn.haxx.se/dev (for dev@).

Use the haxx archives. They're worlds better.

-Travis


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