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
Received on Thu Feb 24 08:29:57 2005