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

Re: [PATCH] new feature: takeover

From: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2005-07-06 00:00:58 CEST

At 08:36 PM 05/07/2005, I wrote:
>The story goes a little bit like this:
>
[snipped: some very long lines]

Sorry for the long lines. My main e-mail client has a bug where when a text
file with UNIX line endings is attached, it is not properly encoded and
lines ending in only 'LF' are sent to the SMTP daemon. The SMTP daemon I'm
using complains about this and refuses to send such messages, so I used an
alternate e-mail client to send the diff (since the HACKING document
specifically says that diffs should NOT be compressed or otherwise
packaged). I didn't realize it would blatantly violate the RFC and not
break lines properly. :-)

I just wanted to add a couple of notes to the first e-mail:

When I added the command to the front-end of the command-line client, I
created an accompanying 'help' page. I preserved the same options that 'svn
checkout' takes, because my new 'svn takeover' is identical in behaviour to
'svn checkout', with the exception of leaving existing files alone (and not
considering them a fatal error).

Up until the code interfaces with the edit script driver & update editor,
the boolean indicating that a takeover is in progress is passed as an
additional parameter to functions (where applicable, I created a new
function, leaving the old interface intact with the old non-takeover
behaviour). Since the actual checking out of files during 'svn checkout' is
done by means of an update, after creating a skeleton .svn directory, the
flag gets passed there too. Once the code creates the svn_delta_editor_t
instance, it ceases to be a parameter; it is instead stored within the
struct. It is pulled back out of the struct and turned into a parameter
again only right before the add_file vtable entry is called, since add_file
does not receive a reference, direct or otherwise, to the editor.

If I've missed any salient points, let me know, and I'll explain any other
changes I've made :-)

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 6 01:01:46 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.