On Thursday 22 September 2005 21:15, Philip Martin wrote:
> "Ph. Marek" <philipp.marek@bmlv.gv.at> writes:
>
> Here's another feature with loads of corner cases!
Well, I didn't write that :-)
> > 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.
I'll try to answer all your questions here, ok?
> > 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?
Sorry, I don't understand you.
The meta-data has exactly one storage point; there can never be a conflict, as
only one value can be stored (for each of owner, group, mtime, mode)
In the current version I let the conflicts happen as with every other property
modification - there's no special code for that.
Which value get's written for the meta-data (if any), I don't know. I haven't
looked at the code for a few months, and got other things on my mind.
What it *should* do? Possibly the same as the early version (2003); I got a
special snippet that checks mtime for conflicts and takes the later value.
But as we don't use branches for the full-meta-data-versioned data (only trunk
and tags), I never really cared - especially since nobody wanted to talk
about my patches :-/
> > 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?
Again, I'm a bit lost what you mean.
I don't have code to handle conflicts specially - there should be exactly the
same behaviour as with normal properties.
And conflicts are not a bad thing, if they tell you "This file was originally
owned by bin, and while the branch went to root, trunk wanted daemon" - it's
necessary to get a human involved to decide.
> How do the versioned permissions interact with svn:executable? What
> happens when they conflict?
Optimally the always agree.
In subversion/libsvn_wc/adm_crawler.c
(http://svn.collab.net/viewcvs/svn/branches/meta-data-versioning/owner-group-mode/subversion/libsvn_wc/adm_crawler.c?rev=13261&view=markup)
you see around line 100 that svn_wc__maybe_set_executable() is before
svn_io_file_set_file_owner_group_mode() - so the stored unix-mode should
override.
Which is the correct thing IMO, as this is the value at the last commit.
> How do versioned permissions interact with umask?
They don't really, as the permissions are set with chmod(), which ignores
umask AFAIK. Only the temporary written files, and files without the
property, depend on 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?
Yes and yes.
As my use-cases were versioning /etc, where some files are readable only by
root, it doesn't matter to me.
But you're right - there should be some notification in the .svn/entries-file,
which says that "original value could not be set - don't send current, but
original value on commit".
But then the user should be able to override this, to set other values...
> 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?
As the properties are only changed/set on commit, a file/directory has to be
committed to get its properties set.
But look - I don't like to spoil a surprise, but it may possibly be the
easiest thing to just do the mtime-patches.
Take a look at http://fsvs.tigris.org/ - I'm a week or two away from the
initial 1.0 release.
That should take care about all these /etc -versioning issues.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 08:50:51 2005