"Ph. Marek" <philipp.marek@bmlv.gv.at> writes:
Here's another feature with loads of corner cases!
> As people standing right in front of something can never see it fully, or
> (other way round) you have to have some distance, I'd beg people to read
> the various commit-logs I've written (see also
> http://svn.haxx.se/dev/archive-2005-02/0005.shtml,
> http://svn.haxx.se/dev/archive-2004-11/att-0411/01-patch-tstamp-svn1.1.1-2.patch,
> and last but not least the issue 1256), and tell me what's missing.
You may have answered the questions in the past, but searching the
mailing list is not a good way for someone else to determine the
behaviour. You need to collect the answers in a single document,
probably stored in the notes/ directory.
> The IMO only point which has still to be discussed is what to do if a file
> get's checked out with owner X, get's locally chown()ed to Y, and updated to
> Z.
> Regarding the modification time there was a discussion not long ago.
>
> I believe it's best (and simplest) if a file about to be committed (because of
> text modifications) just has it current values sent along.
But what does the update do when a conflict arises. We can handle a
conflict in the property itself, but there is no mechanism to handle a
conflict in the meta-data. Which meta-data value does update store?
> So if I check out on date A, do a merge with at time B, then commit would send
> B (the time of the merge) along.
>
> Note: For development purposes the whole discussion about timestamps and make
> may arise again.
> My patches were mostly thought to be used for non-make-situations, ie. where
> no actions were done based on the timestamps.
>
> Perhaps there's need to define another property, which tells to store the
> mtime as currently, but *don't* set it *on update*. export and checkout may
> use it without problems; and if an updated file get's changed, on commit the
> modification time (sic!) is sent - which would be correct, too.
What happens during merge? Do the new properties always conflict?
That would be very user-unfriendly. What about conflicts in the
meta-data itself? What meta-data value gets stored? Are the other
meta-data lost?
How do the versioned permissions interact with svn:executable? What
happens when they conflict?
How do versioned permissions interact with umask?
Owner and group cannot usually be changed unless the user is root.
Does this lead to errors? If a non-root user commits will this result
in the versioned owner group being changed?
As I understand it local meta-data modifications don't show up in
status or diff; in the most recent thread expected to see them. Is
your solution finished or will local modifications one day be visible?
If local modifications are to be visible what happens when the
physical filesystem doesn't support the full resolution of the
versioned timestamp? How do we distinguish that from a local
modification?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 22 21:16:30 2005