On Wed, Aug 03, 2011 at 11:27:48AM +0200, Dominik Psenner wrote:
> > You must still use svn commands instead of OS
> >commands in 1.7. That won't change. I don't think it will ever change.
> >The reason is that Subversion tracks operations explicitly, rather than
> >implicitly. In other words, Subv
>[snip]
>> Subversion is still an observer and whatever a user does, he must tell
>> Subversion what he did in cases where subversion can't
>> understand it by
>> itself (i.e. file/folder rename/move that preserve history across the
>> revisions). Every VCS I know works like this. Maybe one invents
[snip]
> Subversion is still an observer and whatever a user does, he must tell
> Subversion what he did in cases where subversion can't
> understand it by
> itself (i.e. file/folder rename/move that preserve history across the
> revisions). Every VCS I know works like this. Maybe one invents a VC
>I'm not sure you understand the kinds problems the new working copy
>format is settling.
For me it settles the major problem of multiple .svn folders in a checkout.
> You must still use svn commands instead of OS
>commands in 1.7. That won't change. I don't think it will ever change.
>The reason
On Wed, Aug 03, 2011 at 10:25:07AM +0200, Dominik Psenner wrote:
> >Then you must explain it to them. :) To move or delete items in a working
> >copy, you must use svn commands. You must not use OS commands. That's just
> >how it is.
>
> This is going to be a long journey. *jokingly*
>
> Thanks f
>Then you must explain it to them. :) To move or delete items in a working
>copy, you must use svn commands. You must not use OS commands. That's just
>how it is.
This is going to be a long journey. *jokingly*
Thanks for the insights and incredibly fast answers! It's awesome that
you're working o
On Aug 3, 2011, at 03:17, Dominik Psenner wrote:
>> I doubt it. Or rather, the behavior is not broken. The user is broken. As I
>> said: "svn commit foo" should have worked fine if you had not run "rmdir
>> foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by
>> "svn commit f
>I doubt it. Or rather, the behavior is not broken. The user is broken. As I
>said: "svn commit foo" should have worked fine if you had not run "rmdir
>foo" beforehand. Don't run "rmdir foo". Just run "svn rm foo" followed by
>"svn commit foo" and everything should work.
True - it's nothing totall
On Aug 3, 2011, at 03:04, Dominik Psenner wrote:
>> I think "svn commit foo" would work fine, provided you do not "rmdir foo"
>> first; that was your error.
>>
>> I also have a feeling Subversion 1.7's new working copy arrangement will
>> fix or at least change this behavior.
>
> So there's sti
>> I think SVN is behaving correctly. When you do svn commit foo you're
>telling Subversion to commit changes made in foo. There are no changes in
>foo because it's been deleted. The changes, instead, are in its parent
>directory, the one from where you issued your commands. That's why svn
>commi w
>You could also delete the directory directly in the repository using "svn
>delete -m ". This way you would avoid the problem of
>committing partial changes of your working copy.
.. which is just another workaround.
On Aug 2, 2011, at 07:11, Giulio Troccoli wrote:
> On 02/08/11 07:40, Dominik Psenner wrote:
>>
>> having a fresh subversion repository doing this as preparation:
>>
>> $ mkdir foo/
>> $ svn add foo
>> $ svn commit -m "test"
>> Adding foo
>> Revision X sent.
>> $ rmdir foo
>> $ svn st
>> !
On 02/08/11 07:40, Dominik Psenner wrote:
Hi,
having a fresh subversion repository doing this as preparation:
$ mkdir foo/
$ svn add foo
$ svn commit -m "test"
Adding foo
Revision X sent.
$ rmdir foo
$ svn st
! foo
$ svn delete foo
D foo
And finally this command fails:
$ svn co
13 matches
Mail list logo
