On Thursday 18 August 2005 08:45, Branko Čibej wrote:
> Ph. Marek wrote:
> >Excuse me, but I don't seem to understand you.
> >How does that "break" the repository? There's something inconsistent
> > stored - but that's easily repaired.
>
> It's not easily repaired if it means changing properties on a bunch of
> files.
Then let's store pathnames relative to an attribute stored at the repos url.
OK?
> >>>If the /resource-forks path is defined (eg as attribute on REPOS_URL),
> >>> the attributs could be relative to that path - renaming this path would
> >>> take another propset, and everythings ok.
> >>
> >>No, a client that's not aware of this convention won't change the prop,
> >>and will break the repository.
> >
> >A client not aware of this convention won't know how to get or store
> >resource-forks, too, so they will just stay ignored.
>
> It will break the meaning of the repository for clients which _are_
> aware of resource forks.
Why? A non-aware client will update _only_ the data of the file itself, and
should not drop properties at will. So the pointer will stay the same, and as
a non-aware client doesn't know about resource-forks, they just keep the old
value.
If the property gets deleted, well, you get what you deserve :|
BTW, I'd say "don't do that, then", and if it happens, "do a reverse merge".
That's what subversion is for :-)
Sorry - I seem too dense to understand the problems you describe. IMO a
fork-aware-client can update them, and a non-aware-client should ignore them
(that means no modifying or deleting).
Where does your opinion differ?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 18 09:00:23 2005