[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Owner, group, access rights

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-03-07 22:44:38 CET

Adrian May <adrian.may@blue-cell-networks.com> writes:

> Phil layed on some new properties to carry the info around and this
> seems to work, but I'm tying my brain in knots trying to trace the
> whole checkout process through all these batons and logs to the point
> where the file actually exists and can be clobbered with Phil's chmod
> function. Even if I could ride the debugger through all that xml
> parsing stuff to the point where the file finally shows up, I'd then
> have to figure out whether I wanted to change it's properties or
> not. Maybe this info is already hanging around in a baton or
> something, maybe I have to read the property by hand, or maybe I
> should wait until all the other properties are being handled. I guess
> it can't be that different from how svn:executable gets dealt with but
> I didn't suss out how that works either.

The checkout and update processes are more or less the same. The
client parses the XML response from the server, various files get
created in .svn/tmp/, and a log file gets written to .svn/log (there
may be several log files but that's just a performance optimisation).
Once the log file is complete the function svn_wc__run_log is called
which reads the log file, also XML, and "executes" the commands in the
file. These commands move files from .svn/tmp/ into their final place
in the working copy, update properties, update the entries file etc.
When svn_wc__run_log returns the client carries on parsing the XML
response from the server, starts writing another log file, etc.

> I dont mind writing the code myself, but I need to be told what the
> svn architecture would consider the correct stategy to be, otherwise
> I'll get it wrong and make a mess.

The problem with these branches is that there has been very little
discussion about the behaviour that should be implemented. The
current branch code has some fairly arbitrary behaviour that is a
consequence of its implmentation, but there is no guarantee that it
will be accepted in the trunk.

Some, of the many, points of concern:

- Local metadata changes don't get committed unless some other
  text/property change is made.
- How should metadata conflicts get handled?
- Local metadata changes don't show up in status.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 7 22:48:25 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.