subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Adopting unversioned directory on svn up
Date Sun, 04 Dec 2016 17:21:51 GMT
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@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@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.

Mime
View raw message