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

Re: [PATCH] make svnmucc consistently overwrite copy targets

From: <kmradke_at_rockwellcollins.com>
Date: Thu, 6 Nov 2008 16:49:07 -0600

Philip Martin <philip_at_codematters.co.uk> wrote on 11/06/2008 04:33:44 PM:
> kmradke_at_rockwellcollins.com writes:
> > Philip Martin <philip_at_codematters.co.uk> wrote on 11/06/2008 03:56:02
> >>
> >> I don't really like either of those, although 2 is better than 1.
> >> svnmucc is designed to combine simple commands together, what's wrong
> >> with "rm URL1 cp URL2 URL1"?
> >
> > This fails if URL1 didn't exist, so I need to write a wrapper script
> > to check to see if it exists first and then do "rm x cp x y" or
> > else do "cp x y"... That makes it painful for me.
> Or just try one and if it fails try the other.
> > Maybe a third option is to allow rm to fail silently if it doesn't
> > exist?
> I don't like that either; svnmucc is designed to combine commands,
> having an rm silently fail in the middle of a long list is nasty.
> >
> > I'm flexible, I just want to implement something acceptable...
> I think writing a script is the right way to do it.

Problem is, you have to handle a whole bunch of corner conditions
because the check and action are no longer atomic. I.E. it could
exist, you try and delete it, but someone already beat you to
it, but then you just try and cp it, but someone beat you to
it and copied something else, so then you try again, etc.

Granted, I'm not sure what should happen in this extreme case,
but an option to forcibly "copy even if it exists" doesn't
seem too unrealistic, especially since I'm willing to submit the

svnmucc is already inconsistent (at least over DAV). I believe
my original patch made it consistent over all protocols.
(Basically implementing the unix "cp -f" functionality.)

I guess the last option is to just keep my own version or
submit a separate contrib tool with the functionality I need. Ugh...

Kevin R.
Received on 2008-11-06 23:49:30 CET

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.