You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Olaf van der Spek <ml...@vdspek.org> on 2016/11/22 07:56:40 UTC
Adopting unversioned directory on svn up
Hi,
How does one adopt / merge the update from the repo into local
unversioned directories?
Using R marks the directory for deletion.
# svn up /etc
Updating '/etc':
C /etc/php5
A /etc/php5/cli
A /etc/php5/cli/conf.d
A /etc/php5/cgi
A .
Updated to revision 55.
Tree conflict on '/etc/php5'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
(r) - accept current working copy state
(p) - resolve the conflict later [postpone]
(q) - postpone all remaining conflicts
(h) - show this help (also '?')
Words in square brackets are the corresponding --accept option arguments.
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 10:17 PM, Daniel Shahaf <da...@apache.org> wrote:
> Johan Corveleyn wrote on Sun, Dec 04, 2016 at 18:27:48 +0100:
>> It's impossible to say now which files were there before, and which
>> were added by the checkout (OK, the unversioned items were certainly
>> "local files", but the versioned ones ... who knows?
>
> Couldn't you look for files and empty dirs whose ctime/birthtime is
> newer than that of the .svn dir?
Okay, didn't think of that, good suggestion. But it'll still be some
non-trivial work (if it's a large amount of files) to exploit this to
restore the directory to "before the checkout happened".
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Daniel Shahaf <da...@apache.org>.
Johan Corveleyn wrote on Sun, Dec 04, 2016 at 18:27:48 +0100:
> It's impossible to say now which files were there before, and which
> were added by the checkout (OK, the unversioned items were certainly
> "local files", but the versioned ones ... who knows?
Couldn't you look for files and empty dirs whose ctime/birthtime is
newer than that of the .svn dir?
> Except if you kept the notification output of the checkout, so you can
> select all files with a 'E' notification as "those files should be
> kept when I remove the checkout).
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Nov 29, 2016 at 10:19:03PM +0100, Stefan Sperling wrote:
> (Running 'svn add DIR' after
> 'svn revert -R DIR' will also merge the files, but schedules an undesirable
> replacement as well.)
Sorry, the above should say 'svn resolved DIR' instead of 'svn revert -R DIR'.
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Dec 04, 2016 at 11:32:47AM +0100, Olaf van der Spek wrote:
> On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> > I think the most annoying consequence of accidentally checking out
> > over an existing directory, without any conflict detection (if the
> > --force behaviour would be the default), would be that you cannot
> > easily undo the operation. You haven't lost any unversioned data, but
> > you can not easily remove the checkout again and "rollback" to the
> > state before the checkout.
>
> Happened yesterday, I checked out into / instead of /etc.. svn behaves
> slightly different then rsync I guess.
Yeah that can be annoying to clean up after :-/
> > Suppose you have files a and b locally. And the checkout
> > "incorporates" a and b (say they become unmodified because they are
> > the same as the repository version) and adds c, d, e, f, g, ... Oops,
> > the checkout was accidental. Now how do I remove it again? I don't
> > know which files were there before and which were added by the
> > checkout. Now imagine this happening with a complex tree structure
> > with 10,000 directories and 100,000 files.
>
> Does svn have a command to delete all versioned items?
> If not you still have to 'manually' figure out which directories /
> files came from the checkout and which ones existed before.
SVN can show which files and dirs are unversioned with 'svn status'
and list all versioned files and dirs with 'svn list'. That's good
enough to get a list of things, at least.
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
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 <st...@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 <st...@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.
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Mon, Dec 5, 2016 at 12:51 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> I don't understand what you're trying to say here. There are always
> files involved, no? I don't care about the directories themselves in
No, see my initial example:
# svn up /etc
Updating '/etc':
C /etc/php5
A /etc/php5/cli
A /etc/php5/cli/conf.d
A /etc/php5/cgi
A .
Updated to revision 55.
Tree conflict on '/etc/php5'
> local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
The only conflict here is the directory /etc/php5.
I'm not sure what it did though.. the sub-dirs show A instead of C here.
> this case. I'm talking about the --force behaviour of "incorporating"
> existing files to make them part of a checkout that's being checked
> out over an existing tree.
>
>> How often does such an accidental checkout happen anyway?
>
> I have no idea. I suppose it happens from time to time. But in any
> case this discussion is a bit pointless ... we won't change the
> default "non-forcing" behaviour of 'svn checkout', simply because it's
> breaking backwards compatibility.
I'm not sure what that means in this case.. surely Subversion has
changed behavior before?
>> What about checking whether the destination directory exists before
>> the checkout and confirming the checkout is desired if it does exist
>> already?
>
> Yep, that's a good suggestion. As a matter of fact, Patrick Steinhardt
> is currently working on something like this. See this dev@ mail [1]
> with his latest patch. You might want to take a look (the commit
> message in the mail contains a good description of the behaviour).
>
> [1] https://lists.apache.org/thread.html/9ef6d2351c01865ba2e96537fb7b4aa3ff1752b1ace7dd4a95a4e151@%3Cdev.subversion.apache.org%3E
Looks good, thx.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 7:07 PM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sun, Dec 4, 2016 at 6:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
>> So do you agree that the --force behaviour (just blindly incorporating
>> local files, without any warning) should *not* be the default?
>
> I'm not sure..
> Why can't it be the default for directories?
I don't understand what you're trying to say here. There are always
files involved, no? I don't care about the directories themselves in
this case. I'm talking about the --force behaviour of "incorporating"
existing files to make them part of a checkout that's being checked
out over an existing tree.
> How often does such an accidental checkout happen anyway?
I have no idea. I suppose it happens from time to time. But in any
case this discussion is a bit pointless ... we won't change the
default "non-forcing" behaviour of 'svn checkout', simply because it's
breaking backwards compatibility. If we want to improve the experience
for users, we should work on improved tree conflict resolving (as is
currently being worked on for 1.10 --- help is most welcome :-).
> What about checking whether the destination directory exists before
> the checkout and confirming the checkout is desired if it does exist
> already?
Yep, that's a good suggestion. As a matter of fact, Patrick Steinhardt
is currently working on something like this. See this dev@ mail [1]
with his latest patch. You might want to take a look (the commit
message in the mail contains a good description of the behaviour).
[1] https://lists.apache.org/thread.html/9ef6d2351c01865ba2e96537fb7b4aa3ff1752b1ace7dd4a95a4e151@%3Cdev.subversion.apache.org%3E
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sun, Dec 4, 2016 at 6:27 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
> So do you agree that the --force behaviour (just blindly incorporating
> local files, without any warning) should *not* be the default?
I'm not sure..
Why can't it be the default for directories?
How often does such an accidental checkout happen anyway?
What about checking whether the destination directory exists before
the checkout and confirming the checkout is desired if it does exist
already?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Dec 4, 2016 at 11:32 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> I think the most annoying consequence of accidentally checking out
>> over an existing directory, without any conflict detection (if the
>> --force behaviour would be the default), would be that you cannot
>> easily undo the operation. You haven't lost any unversioned data, but
>> you can not easily remove the checkout again and "rollback" to the
>> state before the checkout.
>
> Happened yesterday, I checked out into / instead of /etc.. svn behaves
> slightly different then rsync I guess.
>
>> Suppose you have files a and b locally. And the checkout
>> "incorporates" a and b (say they become unmodified because they are
>> the same as the repository version) and adds c, d, e, f, g, ... Oops,
>> the checkout was accidental. Now how do I remove it again? I don't
>> know which files were there before and which were added by the
>> checkout. Now imagine this happening with a complex tree structure
>> with 10,000 directories and 100,000 files.
>
> Does svn have a command to delete all versioned items?
> If not you still have to 'manually' figure out which directories /
> files came from the checkout and which ones existed before.
I guess you can easily use some output of svn status to find all
versioned items (ignoring the '?' lines, i.e. the unversioned items).
But I don't see how that helps for undoing an accidental "forced"
checkout. The files that were there before your forced checkout might
now be versioned items (i.e. they got a 'E' notification). It's
impossible to say now which files were there before, and which were
added by the checkout (OK, the unversioned items were certainly "local
files", but the versioned ones ... who knows? Except if you kept the
notification output of the checkout, so you can select all files with
a 'E' notification as "those files should be kept when I remove the
checkout).
So do you agree that the --force behaviour (just blindly incorporating
local files, without any warning) should *not* be the default?
FWIW, I agree it would be nice for the conflict resolver to be able to
do this. But as Stefan said, it can't at the moment. If it would have
that functionality, I guess your main request would be fulfilled,
right? Whether --force should be the default for checkout looks like a
secondary question to me (and as I said, I don't think that's a good
idea).
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sun, Dec 4, 2016 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> I think the most annoying consequence of accidentally checking out
> over an existing directory, without any conflict detection (if the
> --force behaviour would be the default), would be that you cannot
> easily undo the operation. You haven't lost any unversioned data, but
> you can not easily remove the checkout again and "rollback" to the
> state before the checkout.
Happened yesterday, I checked out into / instead of /etc.. svn behaves
slightly different then rsync I guess.
> Suppose you have files a and b locally. And the checkout
> "incorporates" a and b (say they become unmodified because they are
> the same as the repository version) and adds c, d, e, f, g, ... Oops,
> the checkout was accidental. Now how do I remove it again? I don't
> know which files were there before and which were added by the
> checkout. Now imagine this happening with a complex tree structure
> with 10,000 directories and 100,000 files.
Does svn have a command to delete all versioned items?
If not you still have to 'manually' figure out which directories /
files came from the checkout and which ones existed before.
And this only applies to files.. it doesn't applies to directories
going into a conflict state right?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Dec 3, 2016 at 10:11 PM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <st...@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 <st...@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?
I think the most annoying consequence of accidentally checking out
over an existing directory, without any conflict detection (if the
--force behaviour would be the default), would be that you cannot
easily undo the operation. You haven't lost any unversioned data, but
you can not easily remove the checkout again and "rollback" to the
state before the checkout.
Suppose you have files a and b locally. And the checkout
"incorporates" a and b (say they become unmodified because they are
the same as the repository version) and adds c, d, e, f, g, ... Oops,
the checkout was accidental. Now how do I remove it again? I don't
know which files were there before and which were added by the
checkout. Now imagine this happening with a complex tree structure
with 10,000 directories and 100,000 files.
So I think it's best not to do this by default.
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Sat, Dec 3, 2016 at 10:07 PM, Stefan Sperling <st...@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 <st...@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?
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
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 <st...@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
> > and forgot to use --force.
>
> I wasn't aware of --force before asking this question.
It's not asking any questions.
> --force is usually used for dangerous stuff as well.
--force is a historcal name everyone is rather unhappy with.
No option named --force should exist (what is being forced?). But it does,
so now we cannot remove it without breaking backwards compatibility.
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Tue, Nov 29, 2016 at 10:19 PM, Stefan Sperling <st...@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.
> As far as I can see, the only nice way to have versioned files merged with
> unversioned files is to use checkout/update with the --force option which
> avoids the tree conflict in the first place. (Running 'svn add DIR' after
> 'svn revert -R DIR' will also merge the files, but schedules an undesirable
> replacement as well.) So this is something the conflict resolver could handle
> in a better way than existing svn commands can.
> However, I'm not very sure how well merging of arbitrary versioned and
> unversioned content generally works out in practice. Is this really more
> useful than one of the other two solutions?
>
> In summary, these are the options the conflict resolver could offer:
> 1) move DIR to another place and restore its versioned content
> 2) discard all unversioned content and put versioned content in place
> 3) merge versioned and unversioned content where paths overlap (like --force)
> Nothing new here, expect the ability to get the same behaviour as with
> update --force after the conflict has been flagged because the user really
> wants to merge the files (why?)
Suppose only directories 'conflict', then there's no danger of
overwriting data and the conflict seems to complicate stuff without
real benefit.
Suppose a file 'conflicts'.. it seems trivial to preserve the existing
file and not mark anything as conflicted. The file will / might show
as modified but that's no problem. No data gets lost.
How do such 'conflicts' happen?
Sometimes a file gets copied / uploaded via SFTP.
Or in the case of me versioning some files in /etc, the system / pkg
installer already created some directories and I'm merely adding some
not yet existing files into them.
> and forgot to use --force.
I wasn't aware of --force before asking this question. --force is
usually used for dangerous stuff as well.
> The biggest advantage of offering such options is that users would not
> have to figure out the resolution steps by themselves.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Nov 29, 2016 at 08:00:31PM +0100, Olaf van der Spek wrote:
> On Tue, Nov 29, 2016 at 7:38 PM, Stefan Sperling <st...@apache.org> wrote:
> > On Tue, Nov 29, 2016 at 07:23:21PM +0100, Olaf van der Spek wrote:
> >> On Wed, Nov 23, 2016 at 12:36 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> >> > Maybe Stefan Sperling (in cc) or others working on the tree conflict
> >> > resolver have more insight on this ...?
> >>
> >> Stefan?
> >>
> >> 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.
If instead you want to make the versioned content of this directory appear
in the working copy, all you need to do is run 'svn revert -R DIR'.
This won't remove unversioned files inside DIR, but these can now be
removed with 'svn cleanup --remove-unversioned DIR' if desired.
Caution: Unlike the update --force option, this overwrites unversioned
files with versioned files where they occupy the same path, instead of
merging such files.
As far as I can see, the only nice way to have versioned files merged with
unversioned files is to use checkout/update with the --force option which
avoids the tree conflict in the first place. (Running 'svn add DIR' after
'svn revert -R DIR' will also merge the files, but schedules an undesirable
replacement as well.) So this is something the conflict resolver could handle
in a better way than existing svn commands can.
However, I'm not very sure how well merging of arbitrary versioned and
unversioned content generally works out in practice. Is this really more
useful than one of the other two solutions?
In summary, these are the options the conflict resolver could offer:
1) move DIR to another place and restore its versioned content
2) discard all unversioned content and put versioned content in place
3) merge versioned and unversioned content where paths overlap (like --force)
Nothing new here, expect the ability to get the same behaviour as with
update --force after the conflict has been flagged because the user really
wants to merge the files (why?) and forgot to use --force.
The biggest advantage of offering such options is that users would not
have to figure out the resolution steps by themselves.
> > Would you like to try writing a patch for this? I think this is a nice
> > problem for someone who would be interested in contributing to the new
> > conflict resolver code.
>
> I'd love to but I'm chronically out of time..
Me too!
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Tue, Nov 29, 2016 at 7:38 PM, Stefan Sperling <st...@apache.org> wrote:
> On Tue, Nov 29, 2016 at 07:23:21PM +0100, Olaf van der Spek wrote:
>> On Wed, Nov 23, 2016 at 12:36 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> > Maybe Stefan Sperling (in cc) or others working on the tree conflict
>> > resolver have more insight on this ...?
>>
>> Stefan?
>>
>> 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.
> Would you like to try writing a patch for this? I think this is a nice
> problem for someone who would be interested in contributing to the new
> conflict resolver code.
I'd love to but I'm chronically out of time..
> I don't know if or when I'll find time to teach the new conflict resolver
> about unversioned obstructions before we release 1.10.0. I'm already rather
> busy with much more difficult resolver problems than this one, problems which
> I consider much more important for SVN's core use cases (such as moves).
> So I believe my time is better spent on these other problems.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@apache.org>.
On Tue, Nov 29, 2016 at 07:23:21PM +0100, Olaf van der Spek wrote:
> On Wed, Nov 23, 2016 at 12:36 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> > Maybe Stefan Sperling (in cc) or others working on the tree conflict
> > resolver have more insight on this ...?
>
> Stefan?
>
> For directories it seems like a no-brainer to avoid the conflict.
Indeed, adding a resolver option for this should not be very difficult.
Would you like to try writing a patch for this? I think this is a nice
problem for someone who would be interested in contributing to the new
conflict resolver code.
I don't know if or when I'll find time to teach the new conflict resolver
about unversioned obstructions before we release 1.10.0. I'm already rather
busy with much more difficult resolver problems than this one, problems which
I consider much more important for SVN's core use cases (such as moves).
So I believe my time is better spent on these other problems.
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Wed, Nov 23, 2016 at 12:36 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>> How does one adopt / merge the update from the repo into local
>>>> unversioned directories?
>>>> Using R marks the directory for deletion.
>>>>
>>>> # svn up /etc
>>>> Updating '/etc':
>>>> C /etc/php5
>>>> A /etc/php5/cli
>>>> A /etc/php5/cli/conf.d
>>>> A /etc/php5/cgi
>>>> A .
>>>> Updated to revision 55.
>>>> Tree conflict on '/etc/php5'
>>>> > local dir unversioned, incoming dir add upon update
>>>> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
>>>>
>>>> (r) - accept current working copy state
>>>> (p) - resolve the conflict later [postpone]
>>>> (q) - postpone all remaining conflicts
>>>> (h) - show this help (also '?')
>>>> Words in square brackets are the corresponding --accept option arguments.
>>>>
>>>> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
>>>
>>> When I know beforehand that I have a local unversioned directory that
>>> maps to a repos-directory that will be incoming when I update, I use
>>> the '--force' option for 'svn up'. That avoids the tree conflicts, and
>>> sort of "integrates" the existing files into your working copy.
>>>
>>> From 'svn help update':
>>> [[[
>>> --force : handle unversioned obstructions as changes
>>> ]]]
>>
>> Nice, how come the interactive interface doesn't provide this option?
>> Or for it to be the default, especially for directories themselves?
>
> (Please keep the list in cc, unless you explicitly want to private-mail me)
>
> You mean: why can't the interactive conflict resolution (after the
> update has been run, and tree conflicts for the entire subtree were
> encountered) not do the same as what 'svn up --force' would have done?
>
> I'm not sure, but I think technically it's different for the conflict
> resolver than for the update driver. The conflict resolver might not
> have the same information at that point anymore, or not the same
> capabilities. But I'm just guessing here.
>
> As a matter of fact, right now work is ongoing on trunk for improved
> tree conflict resolution for SVN 1.10 (if you're interested, you might
> want to follow the dev@ list). I'm not sure if the trunk version of
> the conflict resolver would have offered this capability (or if it
> will still grow this capability).
>
> Maybe Stefan Sperling (in cc) or others working on the tree conflict
> resolver have more insight on this ...?
Stefan?
For directories it seems like a no-brainer to avoid the conflict.
--
Olaf
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 22, 2016 at 4:31 PM, Olaf van der Spek <ml...@vdspek.org> wrote:
> On Tue, Nov 22, 2016 at 9:50 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, Nov 22, 2016 at 8:56 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
>>> Hi,
>>>
>>> How does one adopt / merge the update from the repo into local
>>> unversioned directories?
>>> Using R marks the directory for deletion.
>>>
>>> # svn up /etc
>>> Updating '/etc':
>>> C /etc/php5
>>> A /etc/php5/cli
>>> A /etc/php5/cli/conf.d
>>> A /etc/php5/cgi
>>> A .
>>> Updated to revision 55.
>>> Tree conflict on '/etc/php5'
>>> > local dir unversioned, incoming dir add upon update
>>> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
>>>
>>> (r) - accept current working copy state
>>> (p) - resolve the conflict later [postpone]
>>> (q) - postpone all remaining conflicts
>>> (h) - show this help (also '?')
>>> Words in square brackets are the corresponding --accept option arguments.
>>>
>>> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
>>
>> When I know beforehand that I have a local unversioned directory that
>> maps to a repos-directory that will be incoming when I update, I use
>> the '--force' option for 'svn up'. That avoids the tree conflicts, and
>> sort of "integrates" the existing files into your working copy.
>>
>> From 'svn help update':
>> [[[
>> --force : handle unversioned obstructions as changes
>> ]]]
>
> Nice, how come the interactive interface doesn't provide this option?
> Or for it to be the default, especially for directories themselves?
(Please keep the list in cc, unless you explicitly want to private-mail me)
You mean: why can't the interactive conflict resolution (after the
update has been run, and tree conflicts for the entire subtree were
encountered) not do the same as what 'svn up --force' would have done?
I'm not sure, but I think technically it's different for the conflict
resolver than for the update driver. The conflict resolver might not
have the same information at that point anymore, or not the same
capabilities. But I'm just guessing here.
As a matter of fact, right now work is ongoing on trunk for improved
tree conflict resolution for SVN 1.10 (if you're interested, you might
want to follow the dev@ list). I'm not sure if the trunk version of
the conflict resolver would have offered this capability (or if it
will still grow this capability).
Maybe Stefan Sperling (in cc) or others working on the tree conflict
resolver have more insight on this ...?
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 22, 2016 at 8:56 AM, Olaf van der Spek <ml...@vdspek.org> wrote:
> Hi,
>
> How does one adopt / merge the update from the repo into local
> unversioned directories?
> Using R marks the directory for deletion.
>
> # svn up /etc
> Updating '/etc':
> C /etc/php5
> A /etc/php5/cli
> A /etc/php5/cli/conf.d
> A /etc/php5/cgi
> A .
> Updated to revision 55.
> Tree conflict on '/etc/php5'
> > local dir unversioned, incoming dir add upon update
> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
>
> (r) - accept current working copy state
> (p) - resolve the conflict later [postpone]
> (q) - postpone all remaining conflicts
> (h) - show this help (also '?')
> Words in square brackets are the corresponding --accept option arguments.
>
> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
When I know beforehand that I have a local unversioned directory that
maps to a repos-directory that will be incoming when I update, I use
the '--force' option for 'svn up'. That avoids the tree conflicts, and
sort of "integrates" the existing files into your working copy.
From 'svn help update':
[[[
--force : handle unversioned obstructions as changes
]]]
During the update you'll get 'E' notifications (for "Existed") for all
the items that already exist. Your local files will not be overwritten
by the repos-incoming version. After the update, when you run 'svn
status', some files might show up as (M)odified (if they were
different locally from the repos-incoming version), or not show up if
they were identical.
In your situation, after having already run the update, I'm not sure
what's the best course of action. If it's a separate, new working
copy, you might just throw away the '.svn' directory and start over
(without touching / losing your local files). If it's part of a larger
working copy ... not sure (definitely not "revert" without making a
backup copy of your local files, or you might lose local uncommitted
changes).
--
Johan
Re: Adopting unversioned directory on svn up
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Olaf van der Spek wrote on Tue, Nov 22, 2016 at 10:19:06 +0100:
> On Tue, Nov 22, 2016 at 10:11 AM, Stefan Sperling <st...@elego.de> wrote:
> > Subversion does not version file permissions. You may end up with
> > sensitive files being readable by users other than root (e.g. files
> > such as SSH private host keys).
>
> I'm only versioning 'public' / safe files. And SSH private keys aren't
> in /etc AFAIK, they're in home dirs.
Users' keys are in their homedirs, but host keys are in /etc:
-rw------- 1 root root 668 Jul 6 2014 /etc/ssh/ssh_host_dsa_key
-rw------- 1 root root 227 Jul 6 2014 /etc/ssh/ssh_host_ecdsa_key
-rw------- 1 root root 1675 Jul 6 2014 /etc/ssh/ssh_host_rsa_key
Re: Adopting unversioned directory on svn up
Posted by Olaf van der Spek <ml...@vdspek.org>.
On Tue, Nov 22, 2016 at 10:11 AM, Stefan Sperling <st...@elego.de> wrote:
> This side-steps your actual question but are you sure you want to
> version files in your /etc directory with Subversion?
No ;)
> Subversion does not version file permissions. You may end up with
> sensitive files being readable by users other than root (e.g. files
> such as SSH private host keys).
I'm only versioning 'public' / safe files. And SSH private keys aren't
in /etc AFAIK, they're in home dirs.
But perhaps there's a better way to manage /etc.
Re: Adopting unversioned directory on svn up
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Nov 22, 2016 at 08:56:40AM +0100, Olaf van der Spek wrote:
> Hi,
>
> How does one adopt / merge the update from the repo into local
> unversioned directories?
> Using R marks the directory for deletion.
>
> # svn up /etc
> Updating '/etc':
This side-steps your actual question but are you sure you want to
version files in your /etc directory with Subversion?
Subversion does not version file permissions. You may end up with
sensitive files being readable by users other than root (e.g. files
such as SSH private host keys).
If you have such sensitive files in the repostory, you'll have to make
sure that permissions are still set properly after each svn operation.
This script can help:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn
> C /etc/php5
> A /etc/php5/cli
> A /etc/php5/cli/conf.d
> A /etc/php5/cgi
> A .
> Updated to revision 55.
> Tree conflict on '/etc/php5'
> > local dir unversioned, incoming dir add upon update
> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h
>
> (r) - accept current working copy state
> (p) - resolve the conflict later [postpone]
> (q) - postpone all remaining conflicts
> (h) - show this help (also '?')
> Words in square brackets are the corresponding --accept option arguments.
>
> Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help:
>
>
> --
> Olaf