> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: woensdag 28 maart 2012 17:25
> To: Daniel Shahaf
> Cc: Bert Huijben; Philip Martin; users_at_subversion.apache.org
> Subject: Re: svn 1.7: how to recover from a lost pristine file
>
> On Wed, Mar 28, 2012 at 5:06 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
> > Johan Corveleyn wrote on Wed, Mar 28, 2012 at 16:38:41 +0200:
> >> Thanks both for your help. Maybe this will help others running in the
> >> same situation ...
> >
> > Do you know what cause the pristine to disappear in the first place?
>
> No, not yet. When I have some more time I'll try to reproduce it.
>
> In the meantime, I experimented a bit more with '--set-depth exclude',
> just to see what happens when you do this on a modified file. It's
> interesting (but maybe this is all normal, can't say ... just
> interesting :-)):
>
> [[[
> C:\WC>echo test >> build.properties
>
> C:\WC>svn-1.7 st
> M build.properties
>
> C:\WC>svn-1.7 up --set-depth exclude build.properties
> D build.properties
>
> C:\WC>svn-1.7 st
> ? build.properties
>
> C:\WC>svn-1.7 up build.properties
> Updating 'build.properties':
> C build.properties
> At revision 176270.
> Summary of conflicts:
> Tree conflicts: 1
>
> ### argh, a tree conflict. Panic! :-)
>
> C:\WC>svn-1.7 st
> D C build.properties
> > local unversioned, incoming add upon update
> Summary of conflicts:
> Tree conflicts: 1
>
> ### let's try to recover from this.
>
> C:\WC>svn-1.7 resolve --accept=working build.properties
> Resolved conflicted state of 'build.properties'
Don't assume that svn resolve --accept=<anything> makes much sense for tree
conflicts. Sorry.
We accept this format as a way to accept the tree conflict, but it assumes
that you did the actual resolving yourself.
> C:\WC>svn-1.7 st
> D build.properties
>
> ### hm, how do I get it back as un-deleted without losing my mods
We don't have obstruction conflicts (yet), so an incoming file that is
blocked by something unversioned is marked as deleted.
This should really be some kind of obstruction conflict to make sure
Subversion doesn't try to change the local file on other operations.
Currently [D]eleted is the only state with that behavior.
> C:\WC>svn-1.7 add build.properties
> A build.properties
This adds a replacement over your deleted file. So I would expect this
> C:\WC>svn-1.7 st
> RM build.properties
And I think your settings automatically applied properties here. (The M is
for properties modified)
> ### cool! I've never seen 'RM' before. Anyway, this is not what I wanted
:-(
Bert
Received on 2012-03-28 17:50:00 CEST