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

Commit access request

From: <dimentiy_at_dimentiy.info>
Date: 2003-05-28 10:33:47 CEST

Hi, dev@ !

Currently I'm translating svnbook into russian language (~40% done).
I'm request commit access for area with path like /doc/translations/russian.

--
Sincerely, Dimentiy.
> -----Original Message-----
> From: kfogel@newton.ch.collab.net 
> [mailto:kfogel@newton.ch.collab.net] On Behalf Of kfogel@collab.net
> Sent: Wednesday, May 28, 2003 9:36 AM
> To: Greg Hudson
> Cc: dev@subversion.tigris.org
> Subject: Re: RFC: Make apply_textdelta unconditional
> 
> 
> Greg Hudson <ghudson@MIT.EDU> writes:
> > Really?  Why?  Right now, the two bits of information are always in
> > sync; we instruct delta_dirs to send a skeletal edit 
> precisely when the
> > editor isn't going to request deltas anyway.  I can't imagine any
> > situation where we wouldn't want them to be in sync.  And if you did
> > accidentally feed a skeletal edit to a driver which wants 
> text deltas,
> > something horrible would happen, like working copy corruption.
> > 
> > Unless there's a compelling reason for both parties to be 
> in control of
> > a negotiation, it's usually simpler and less error-prone 
> for one party
> > to make the decision unilaterally.
> 
> The more I think about it, the more sense that makes -- specifically,
> for the driver to be in control (and not just because it's called "the
> driver", but because of what it is).  The driver will always know what
> it's trying to do.  If its task doesn't need text deltas, it can send
> the null window.  If the task does need them, it should send them.
> 
> > That would be terrible.  You'd get situations where code 
> can work with
> > ra_local (or with ra_dav, because ra_dav is so divorced 
> from the regular
> > API) but not with ra_svn.  You'd have all this meaningless 
> flexibility,
> > with the addition of a big fat land mine which will go off 
> if you ever
> > use it.
> 
> Hmmm.  I have to admit, you've got me there :-).
> 
> I think I'm +1 on this (thanks for taking the time to help me work
> through it).
> 
> I'd prefer for Greg Stein to have a chance to see the proposal.  But
> he's off at a convention right now, and may need a few days to catch
> up with the list.  Is your schedule such that you need to do this
> change right away?
> 
> -Karl
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 10:35:20 2003

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.