> >After all this discussing I still believe that the stored properties
> > should be used *only* on export, so that build tools see which data has
> > changed.
>
> Did that truly mean "only export"? Or "export and checkout"? Just
> trying to clarify your intent, not expressing an opinion at this
> point.
Well, as already discussed, it would work for checkout *only* if it was a
clean checkout (ie an entire tree, not single files - else the relative times
are wrong wrt make), and a checkout on source files normally means that I'm
going to work on them - which changes the timestamps to values not in the
repository (at least with the next update, which I take as given uses current
time).
> Philipp, you're terrifying me. :-) Your proposal, so far, is to add
> at least three humongous new features:
>
> 1. so far, your patches have tried to create a new 'svn:' property
> for original timestamp preservation, so imports can remember the
> original unversioned mtime, rather than the commit-time. You've
> even proposed a whole new class of 'noneditable' properties
> living in the editable user space. (I think you started coding
> this before you realized we already non-editable 'entry' props
> living in .svn/entries... but still...)
>
> 2. You want a new property for binary-files that determines whether
> to use the commit-time or 'now' time.
>
> 3. Your solution requires property inheritance, which is another
> feature we don't have, and have discussed many times. (It's very
> *hard* to implement that, and it's been punted many times.)
To accomplish all goals and to give every user all that he wants takes some
coding :-)
But no. I don't suggest adding all these.
- AFAIK the entry-properties are living only in the wc and are not saved in
the repository.
- I'd have this property for all files - not just binary.
- and the property inheritance is something I believed was already working -
at least I remember reading something in the book. But possibly I'm wrong.
As I myself don't see an easy way to do this I'd leave it for now. Maybe it's
easier to use a wc-property which can be easily be set in all directories at
checkout time, and on subdirectory creating inheriting from the parent.
> At the moment, I still feel like the best solution is to mimic the CVS
> behavior:
>
> * it keeps developers and release-managers happy 90% of the time, and
> easily ignorable by people who don't care.
>
> * no surprises for former CVS users.
>
> * it only requires extremely trivial code changes; no new
> properties, no stored properties, no huge new features. Just a
> small tweak to libsvn_wc.
>
> In other words, it's a path of very low resistance, but still
> "scratches the itch" of timestamps pretty effectively.
>
> Phillip, can you talk about why you like/dislike the CVS behavior?
It's the problem of files ordering. I have to administer a whole lot of files,
which are a) binary b) not modifieable by me c) have to have their timestamps
correct as issued to me (because a timestamp-based copy (update only newer
files) is needed).
I don't like that CVS makes binary handling hard, that the files are
independent from each other, and that the timestamps are not saved.
I got attracted by svn because it handles binary files without the user, saved
*only* the binary changes (which makes a whole lotta difference if you've got
40 nearly identical versions of a 70MB binary file :-). Complete tree states
are saved (which I *really like*), commits are atomic (say goodbye, cvs ...)
and it promises that file meta-data is saved (I remember something about
possible acl, timestamps, access rights, ... save/restore support).
In short, everything that svn tries to do better than cvs.
As I learned that svn doesn't do timestamps (which I require), I set out to
implement them. I know that the decision is not easy - but I got some
responses telling me that mtime restoration is needed not only by me.
So I'm perfectly happy if the default behaviour is to mimic CVS; but I need
something to give consistent snapshots with at least mtimes to other people.
(At least for export - in my wc the meta-data is not as important)
So, seeing it one way, I read a promise from svn lips, which it doesn't hold
right now :-)
My question is now - if the current implemented behaviour - ie. restoration on
export, saving on import, add, commit, a "hidden" svn property - is given to
you as a patch, remarks included, no changes to the "update" functionality
(apart from hiding the property) -- are there any wishes, remarks, comments,
etc., or is there at least a 50:50 chance that someone looks at the patch?
Please, please! |-\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 26 07:43:50 2003