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

Re: Adopting unversioned directory on svn up

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 4 Dec 2016 18:21:51 +0100

On Sat, Dec 03, 2016 at 10:11:49PM +0100, Olaf van der Spek wrote:
> On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Sat, Dec 03, 2016 at 06:42:11PM +0100, Olaf van der Spek wrote:
> >> On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> >> >> >> For directories it seems like a no-brainer to avoid the conflict.
> >> >> >
> >> >> > Indeed, adding a resolver option for this should not be very difficult.
> >> >>
> >> >> I'd opt for not having a conflict in the first place.
> >> >
> >> > There is a reason the non-conflict behaviour requires the --force option.
> >> > It is perfectly fine for Subversion to be conservative if the alternative
> >> > is to litter all over other people's data.
> >> >
> >> > And this conflict is not very difficult to solve:
> >> >
> >> > When a directory DIR has an "local dir unversioned, incoming dir add upon
> >> > update" conflict, and you want to keep DIR as it was and do not want SVN
> >> > to touch it after all, all you need to do is move DIR out of the working
> >> > copy (with standard operating system tools) to somewhere else and it will
> >> > have been preserved as it was before SVN got involved.
> >> > Then run 'svn revert -R DIR' to put the versioned content in place.
> >> > Note that this solution is not trivial to achieve after update --force
> >> > which might modify unversioned files, requiring the user to edit files
> >> > in DIR back into their original state. This is why --force is not the default.
> >>
> >> Are you sure?
> >> In my experience --force does NOT overwrite existing files.
> >> Not overwriting files is safe and exactly what I want.
> >
> > I am quite sure:
> >
> > $ cd trunk-wc
> > $ ls
> > alpha beta epsilon/ gamma/
> > $ cat epsilon/zeta
> > zeta
> > $ cd ..
> > $ rm -rf trunk-wc
> > $ mkdir -p trunk-wc/epsilon
> > $ echo zzz > trunk-wc/epsilon/zeta
> > $ svn co --force file:///tmp/svn-sandbox/repos/trunk trunk-wc
> > A trunk-wc/alpha
> > A trunk-wc/beta
> > E trunk-wc/epsilon
> > E trunk-wc/epsilon/zeta
> > A trunk-wc/gamma
> > A trunk-wc/gamma/delta
> > Checked out revision 2.
> > $ svn diff trunk-wc
> > Index: trunk-wc/epsilon/zeta
> > ===================================================================
> > --- trunk-wc/epsilon/zeta (revision 2)
> > +++ trunk-wc/epsilon/zeta (working copy)
> > @@ -1 +1 @@
> > -zeta
> > +zzz
>
> So what unversioned file was overwritten by --force?
> zeta wasn't modified by the checkout was it?

Yes, you are right. Sorry! It seems I got confused about whether we
were talking about versioned or unversioned content being changed.

And at some point I was sure it would create text conflicts but in
fact it seems to leave unversioned files as-is.
Received on 2016-12-04 18:22:16 CET

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

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