Re: Compare revisions on different devices, why different?
Den fre 10 dec. 2021 kl 17:02 skrev Stefan Sperling : > On Fri, Dec 10, 2021 at 04:57:03PM +0100, Bo Berglund wrote: > > So the update did nothing except fix the revision number and time stamp. > > > > Do you need to do an svn up after each svn ci in order to fix the state? > > Yes. See here for an explanation: > https://subversion.apache.org/faq.html#hidden-log While svn up solves this particular issue, in normal operation it is seldom required. There are a few operations that doesn't work (or doesn't work well) on a mixed revision wc, for example merges and setting properties on the directory itself. But in general it is quite seldom I run svn up unless I want to fetch new revisions from the server. Kind regards, Daniel
Re: Compare revisions on different devices, why different?
On Fri, Dec 10, 2021 at 04:57:03PM +0100, Bo Berglund wrote: > So the update did nothing except fix the revision number and time stamp. > > Do you need to do an svn up after each svn ci in order to fix the state? Yes. See here for an explanation: https://subversion.apache.org/faq.html#hidden-log
Re: Compare revisions on different devices, why different?
On Fri, 10 Dec 2021 10:14:24 -0500, Nathan Hartman wrote: >> Why are they not at the samerevision and date? >> >> > >On the debug system, immediately after committing, did you do 'svn update'? > >Nathan No, I assumed that was not needed since the debug system is where I have done code changes lately. But this fixed the issue: $ svn up Updating '.': At revision 4474. $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer ... Revision: 4474 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4474 Last Changed Date: 2021-12-10 07:13:39 -0600 (Fri, 10 Dec 2021) So the update did nothing except fix the revision number and time stamp. Do you need to do an svn up after each svn ci in order to fix the state? -- Bo Berglund Developer in Sweden
Re: Compare revisions on different devices, why different?
On Fri, Dec 10, 2021 at 10:13 AM Bo Berglund wrote: > > I have several devices on which I have checked out the same project. > One is connected to a debugging external system and the others are not. > Now I have been working on the debugging system and committed my changes from > that. > Then I have updated the project on the non-debug system expecting to get the > same code on both. > But this is what svn info gets me: > > Debug system where I just committed: > > $ svn info > Path: . > Working Copy Root Path: /home/pi/projects/SSRemoteServer > URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source > Relative URL: ^/SSRemoteServer/trunk/source > Repository Root: https://mysvnserver/svn/pc > Repository UUID: 1e489663-c639-2248-90da-e976bc628839 > Revision: 4470 > Node Kind: directory > Schedule: normal > Last Changed Author: bosse > Last Changed Rev: 4470 > Last Changed Date: 2021-09-23 02:55:51 -0500 (Thu, 23 Sep 2021) > > Code writing system where I just updated: > - > $ svn info > Path: . > Working Copy Root Path: /home/pi/projects/SSRemoteServer > URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source > Relative URL: ^/SSRemoteServer/trunk/source > Repository Root: https://mysvnserver/svn/pc > Repository UUID: 1e489663-c639-2248-90da-e976bc628839 > Revision: 4474 > Node Kind: directory > Schedule: normal > Last Changed Author: bosse > Last Changed Rev: 4474 > Last Changed Date: 2021-12-10 14:13:39 +0100 (Fri, 10 Dec 2021) > > I note that these items differ: > --- > Revision: 4470 vs 4474 > Last Changed Rev: 4470 vs 4474 > Last Changed Date: 2021-09-23 vs 2021-12-10 > > Why are they not at the samerevision and date? > > > -- > Bo Berglund > Developer in Sweden > On the debug system, immediately after committing, did you do 'svn update'? Nathan
Compare revisions on different devices, why different?
I have several devices on which I have checked out the same project. One is connected to a debugging external system and the others are not. Now I have been working on the debugging system and committed my changes from that. Then I have updated the project on the non-debug system expecting to get the same code on both. But this is what svn info gets me: Debug system where I just committed: $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source Relative URL: ^/SSRemoteServer/trunk/source Repository Root: https://mysvnserver/svn/pc Repository UUID: 1e489663-c639-2248-90da-e976bc628839 Revision: 4470 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4470 Last Changed Date: 2021-09-23 02:55:51 -0500 (Thu, 23 Sep 2021) Code writing system where I just updated: - $ svn info Path: . Working Copy Root Path: /home/pi/projects/SSRemoteServer URL: https://mysvnserver/svn/pc/SSRemoteServer/trunk/source Relative URL: ^/SSRemoteServer/trunk/source Repository Root: https://mysvnserver/svn/pc Repository UUID: 1e489663-c639-2248-90da-e976bc628839 Revision: 4474 Node Kind: directory Schedule: normal Last Changed Author: bosse Last Changed Rev: 4474 Last Changed Date: 2021-12-10 14:13:39 +0100 (Fri, 10 Dec 2021) I note that these items differ: --- Revision: 4470 vs 4474 Last Changed Rev: 4470 vs 4474 Last Changed Date: 2021-09-23 vs 2021-12-10 Why are they not at the samerevision and date? -- Bo Berglund Developer in Sweden
Re: ASF Subversion version
Gotcha, thank you. > On Dec 10, 2021, at 7:14 AM, Mark Phippard wrote: > > On Fri, Dec 10, 2021 at 8:12 AM Luke Mauldin wrote: >> >> I noticed that the ASF is still running Subversion 1.9.x which was released >> quite a few years ago. Does anyone know why they haven’t at least upgraded >> to the 10.x LTS release which itself is over 2 years old at this point? > > ASF Infra uses the package provided by the Linux distro they are using > rather than building and maintaining their own package. > > Mark
Re: ASF Subversion version
On Fri, Dec 10, 2021 at 8:12 AM Luke Mauldin wrote: > > I noticed that the ASF is still running Subversion 1.9.x which was released > quite a few years ago. Does anyone know why they haven’t at least upgraded to > the 10.x LTS release which itself is over 2 years old at this point? ASF Infra uses the package provided by the Linux distro they are using rather than building and maintaining their own package. Mark
ASF Subversion version
I noticed that the ASF is still running Subversion 1.9.x which was released quite a few years ago. Does anyone know why they haven’t at least upgraded to the 10.x LTS release which itself is over 2 years old at this point? Luke
Re: svn::auto-props and svn:needs-lock
Den tors 9 dec. 2021 kl 11:18 skrev Sebastian Weilhammer < sebastian.weilham...@madheadgames.com>: > Is that not what I'm doing by setting svn:auto-props to *= on the child > node? > I have tried the following, I think this is matches what you are trying to do. This is done using Subversion 1.14.1: [[[ D:\Dev\test_trunk>mkdir X D:\Dev\test_trunk>svn add X A X D:\Dev\test_trunk>svn propset svn:auto-props "*=svn:needs-lock=*" X property 'svn:auto-props' set on 'X' D:\Dev\test_trunk>echo "xx" >X\xx D:\Dev\test_trunk>svn add X\xx A X\xx D:\Dev\test_trunk>mkdir X\Y D:\Dev\test_trunk>svn add X\Y A X\Y D:\Dev\test_trunk>echo "xy" >X\Y\xy D:\Dev\test_trunk>svn add X\Y\xy A X\Y\xy D:\Dev\test_trunk>svn proplist -vR X Properties on 'X': svn:auto-props *=svn:needs-lock=* Properties on 'X\Y\xy': svn:needs-lock * Properties on 'X\xx': svn:needs-lock * ]]] So far nothing remarkable: the file X\xx got svn:needs-lock=* as expected. X\Y\xy also got it, which shows that the svn:auto-props is recursive (as indicated by Justin). [[[ D:\Dev\test_trunk>svn propset svn:auto-props "*=svn:needs-lock=" X\Y property 'svn:auto-props' set on 'X\Y' D:\Dev\test_trunk>echo "xy2" >X\Y\xy2 D:\Dev\test_trunk>svn add X\Y\xy2 A X\Y\xy2 D:\Dev\test_trunk>svn proplist -vR X Properties on 'X': svn:auto-props *=svn:needs-lock=* Properties on 'X\Y': svn:auto-props *=svn:needs-lock= Properties on 'X\Y\xy': svn:needs-lock * Properties on 'X\Y\xy2': svn:needs-lock * Properties on 'X\xx': svn:needs-lock * D:\Dev\test_trunk> ]]] Now, I think what you are asking is why X\Y\xy2 gets svn:needs-lock and if there is a way to avoid it? I think this is an interesting question and it doesn't seem to be handled very well in my opinion. I *feel* that the *=svn:needs-lock= should be handled as "don't set svn:needs-lock at all" but as you say, svn:needs-lock doesn't require a specific value to apply, which is probably why it is set on X\Y\xy2. This might be a "by design" think, or it might be something that we can consider to change. I hope to find the time to look a little more closely during the holidays. Kind regards, Daniel >
