Re: --revision option is not forwarded to svn:externals references

[Harald Oehlmann]

Am 03.10.2022 um 15:53 schrieb Alfred von Campe:



On Sep 28, 2022, at 7:10, Harald Oehlmann  wrote:

I will see, if I can work around it with SVN. I just told myself a fool, as I 
thought for 20 years, that this basic requirement was no problem, but it is.


I’ve used a script that would enumerate the externals and used the ‘{DATE}’ format 
to update the externals to the same date as the main branch.  Just get the date with 
something like "svn info | awk '/Last Changed Date:/ {print $4, $5}’”.

Alfred


Alfred,
that is great, thank you ! As I use one repository, I even don't need 
the date trick. I can directly go with the revision number.
"date" is not precise enough for me, as I have multiple commits per day 
and I want an exact one.
I had a srcipt on WIndows, which worked for externals on folders. 
Unfortunately, I have no script which handles externals on files.
The script searches for ".svn" folders and runs "svn up -r 1234" on 
those folders. Unfortunately, this does not wqork on externals on files.


Thank you for all,
Harald


OpenPGP_signature
Description: OpenPGP digital signature

Re: --revision option is not forwarded to svn:externals references

[Alfred von Campe]

> On Sep 28, 2022, at 7:10, Harald Oehlmann  wrote:
> 
> I will see, if I can work around it with SVN. I just told myself a fool, as I 
> thought for 20 years, that this basic requirement was no problem, but it is.

I’ve used a script that would enumerate the externals and used the ‘{DATE}’ 
format to update the externals to the same date as the main branch.  Just get 
the date with something like "svn info | awk '/Last Changed Date:/ {print $4, 
$5}’”.  

Alfred

Re: --revision option is not forwarded to svn:externals references

[Harald Oehlmann]

Am 28.09.2022 um 12:59 schrieb Daniel Sahlberg:
Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann 
mailto:harald.oehlm...@elmicron.de>>:


Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg:
 > Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann
 > mailto:harald.oehlm...@elmicron.de>
>>:
 >
 >     ( I have chosen the same title as SVN-2516, as it addresses
the same
 >     issue )
 >
 >     Thank you for great subversion. I am a happy user with
TortoiseSVN on
 >     Windows with a Linux server since 20 years.
 >
 >     I was hit by a quality department request to restore a
revision, I have
 >     tagged before. Unfortunately, this does not work, if there are
 >     externals
 >     on externals.
 >
 >     I have only one repository and the externals all go to the same
 >     repository.
 >
 >     There are hints on stack overflow to run over the files and
search for
 >     any ".svn" folder and call "svn up -r 123" if they are found.
 >     That is great. Unfortunately, I use a lot of externals only
to one file
 >     (typically image files for buttons).
 >
 >     I find it really sad, that there is no command:
 >
 >     "svn up -r 123 -propage-externals", which will checkout also the
 >     externals, as if "-r 123" would be set for the externals.
 >     For me, this is the main point missing in SVN and a blocker
for any
 >     use,
 >     as a tagged version may never be restored and the quality
department
 >     will say to you: you are not able to reproduce the source code.
 >
 >
 > I assume your externals property doesn't specify a PEG revision
(see the
 > SVN book [1]). If you did, then the external would update to that
 > particular peg revision, otherwise the peg revision defaults to HEAD.
 >
 > In /trunk it is probably tempting to have the externals tracking
HEAD.
 > But when you tag a release it should be part of your process to
freeze
 > all externals to a certain point in time (either to switch them to a
 > specific tag or pegging them to a revision). That way you can
easily go
 > back in time to and restore the complete working copy. The
TortoiseSVN
 > repository [2] is using this for all release tags, they are
updating all
 > externals to the desired tag in the external repository.
 >
 > As for your use case, I can see a point in having the externals
 > definition default to the same revision as the rest of the
working copy
 > (since they are in the same repository and share the same revision
 > number sequence). But I feel the same way as C. Michael Pilato in
his
 > first comment: "The disparity between behaviors for externals that
 > happen to point to the same repository and those that point to a
 > different repository bothers me.". It will for sure make things more
 > difficult to explain if externals pointing to another repository
default
 > to HEAD while intra-repository externals point to "same revision"
(that
 > would be BASE, I think).
 >
 > Kind regards,
 > Daniel
 >
 >
 > [1]
https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

 > >
 > [2] https://osdn.net/projects/tortoisesvn/scm/svn/

 > >
 >

Dear Daniel,

thank you for the answer.
No, there are no PEG-revisions in the externals. I don't want them. I
have two use-cases, where SVN is apparently not the solution:

R1) always have the head in externals (normal developping mode)
R2) be able to check-out an exact version, as it was checked out with a
distinct version later on (mode to get again, what was true before for
quality/archiving/documentation purposes.

The advice "use a versioned external" does not help, as this
contradicts
R1). Tagging a version works for externals, but not for externals on
externals.


Well, both use cases are possible, just not at the same time.

For me, it is hard to understand that this is wanted like that. For me,
a revision system should have the capability to checkpoint. But it has
not. I can understand, that multiple repositories is another story. But
the power of SVN is, to have one exact revision number which gives
everything. And it is sad, that this great tool is not usable for
externals.


For me, the argument by Mike (as quoted already) that Subversion 

Re: --revision option is not forwarded to svn:externals references

[Daniel Sahlberg]

Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann <
harald.oehlm...@elmicron.de>:

> Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg:
> > Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann
> > mailto:harald.oehlm...@elmicron.de>>:
> >
> > ( I have chosen the same title as SVN-2516, as it addresses the same
> > issue )
> >
> > Thank you for great subversion. I am a happy user with TortoiseSVN on
> > Windows with a Linux server since 20 years.
> >
> > I was hit by a quality department request to restore a revision, I
> have
> > tagged before. Unfortunately, this does not work, if there are
> > externals
> > on externals.
> >
> > I have only one repository and the externals all go to the same
> > repository.
> >
> > There are hints on stack overflow to run over the files and search
> for
> > any ".svn" folder and call "svn up -r 123" if they are found.
> > That is great. Unfortunately, I use a lot of externals only to one
> file
> > (typically image files for buttons).
> >
> > I find it really sad, that there is no command:
> >
> > "svn up -r 123 -propage-externals", which will checkout also the
> > externals, as if "-r 123" would be set for the externals.
> > For me, this is the main point missing in SVN and a blocker for any
> > use,
> > as a tagged version may never be restored and the quality department
> > will say to you: you are not able to reproduce the source code.
> >
> >
> > I assume your externals property doesn't specify a PEG revision (see the
> > SVN book [1]). If you did, then the external would update to that
> > particular peg revision, otherwise the peg revision defaults to HEAD.
> >
> > In /trunk it is probably tempting to have the externals tracking HEAD.
> > But when you tag a release it should be part of your process to freeze
> > all externals to a certain point in time (either to switch them to a
> > specific tag or pegging them to a revision). That way you can easily go
> > back in time to and restore the complete working copy. The TortoiseSVN
> > repository [2] is using this for all release tags, they are updating all
> > externals to the desired tag in the external repository.
> >
> > As for your use case, I can see a point in having the externals
> > definition default to the same revision as the rest of the working copy
> > (since they are in the same repository and share the same revision
> > number sequence). But I feel the same way as C. Michael Pilato in his
> > first comment: "The disparity between behaviors for externals that
> > happen to point to the same repository and those that point to a
> > different repository bothers me.". It will for sure make things more
> > difficult to explain if externals pointing to another repository default
> > to HEAD while intra-repository externals point to "same revision" (that
> > would be BASE, I think).
> >
> > Kind regards,
> > Daniel
> >
> >
> > [1] https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
> > 
> > [2] https://osdn.net/projects/tortoisesvn/scm/svn/
> > 
> >
>
> Dear Daniel,
>
> thank you for the answer.
> No, there are no PEG-revisions in the externals. I don't want them. I
> have two use-cases, where SVN is apparently not the solution:
>
> R1) always have the head in externals (normal developping mode)
> R2) be able to check-out an exact version, as it was checked out with a
> distinct version later on (mode to get again, what was true before for
> quality/archiving/documentation purposes.
>
> The advice "use a versioned external" does not help, as this contradicts
> R1). Tagging a version works for externals, but not for externals on
> externals.
>

Well, both use cases are possible, just not at the same time.


> For me, it is hard to understand that this is wanted like that. For me,
> a revision system should have the capability to checkpoint. But it has
> not. I can understand, that multiple repositories is another story. But
> the power of SVN is, to have one exact revision number which gives
> everything. And it is sad, that this great tool is not usable for
> externals.
>

For me, the argument by Mike (as quoted already) that Subversion should
behave identically whether or not the external is an internal or external
repository has higher priority. But I would not stand in the way of
consensus if others believe your suggestion is sound.

Considering the low number of developers working on this, any help is
appreciated. I'm sure if you would like to contribute the code to change
Subversion's behaviour you would get the necessary support on the dev@ list
to have this committed.

Kind regards,
Daniel

Re: --revision option is not forwarded to svn:externals references

[Harald Oehlmann]

Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg:
Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann 
mailto:harald.oehlm...@elmicron.de>>:


( I have chosen the same title as SVN-2516, as it addresses the same
issue )

Thank you for great subversion. I am a happy user with TortoiseSVN on
Windows with a Linux server since 20 years.

I was hit by a quality department request to restore a revision, I have
tagged before. Unfortunately, this does not work, if there are
externals
on externals.

I have only one repository and the externals all go to the same
repository.

There are hints on stack overflow to run over the files and search for
any ".svn" folder and call "svn up -r 123" if they are found.
That is great. Unfortunately, I use a lot of externals only to one file
(typically image files for buttons).

I find it really sad, that there is no command:

"svn up -r 123 -propage-externals", which will checkout also the
externals, as if "-r 123" would be set for the externals.
For me, this is the main point missing in SVN and a blocker for any
use,
as a tagged version may never be restored and the quality department
will say to you: you are not able to reproduce the source code.


I assume your externals property doesn't specify a PEG revision (see the 
SVN book [1]). If you did, then the external would update to that 
particular peg revision, otherwise the peg revision defaults to HEAD.


In /trunk it is probably tempting to have the externals tracking HEAD. 
But when you tag a release it should be part of your process to freeze 
all externals to a certain point in time (either to switch them to a 
specific tag or pegging them to a revision). That way you can easily go 
back in time to and restore the complete working copy. The TortoiseSVN 
repository [2] is using this for all release tags, they are updating all 
externals to the desired tag in the external repository.


As for your use case, I can see a point in having the externals 
definition default to the same revision as the rest of the working copy 
(since they are in the same repository and share the same revision 
number sequence). But I feel the same way as C. Michael Pilato in his 
first comment: "The disparity between behaviors for externals that 
happen to point to the same repository and those that point to a 
different repository bothers me.". It will for sure make things more 
difficult to explain if externals pointing to another repository default 
to HEAD while intra-repository externals point to "same revision" (that 
would be BASE, I think).


Kind regards,
Daniel


[1] https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html 

[2] https://osdn.net/projects/tortoisesvn/scm/svn/ 





Dear Daniel,

thank you for the answer.
No, there are no PEG-revisions in the externals. I don't want them. I 
have two use-cases, where SVN is apparently not the solution:


R1) always have the head in externals (normal developping mode)
R2) be able to check-out an exact version, as it was checked out with a 
distinct version later on (mode to get again, what was true before for 
quality/archiving/documentation purposes.


The advice "use a versioned external" does not help, as this contradicts 
R1). Tagging a version works for externals, but not for externals on 
externals.


For me, it is hard to understand that this is wanted like that. For me, 
a revision system should have the capability to checkpoint. But it has 
not. I can understand, that multiple repositories is another story. But 
the power of SVN is, to have one exact revision number which gives 
everything. And it is sad, that this great tool is not usable for externals.


Thank you again,
Harald


OpenPGP_signature
Description: OpenPGP digital signature

Re: --revision option is not forwarded to svn:externals references

[Daniel Sahlberg]

Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann <
harald.oehlm...@elmicron.de>:

> ( I have chosen the same title as SVN-2516, as it addresses the same issue
> )
>
> Thank you for great subversion. I am a happy user with TortoiseSVN on
> Windows with a Linux server since 20 years.
>
> I was hit by a quality department request to restore a revision, I have
> tagged before. Unfortunately, this does not work, if there are externals
> on externals.
>
> I have only one repository and the externals all go to the same repository.
>
> There are hints on stack overflow to run over the files and search for
> any ".svn" folder and call "svn up -r 123" if they are found.
> That is great. Unfortunately, I use a lot of externals only to one file
> (typically image files for buttons).
>
> I find it really sad, that there is no command:
>
> "svn up -r 123 -propage-externals", which will checkout also the
> externals, as if "-r 123" would be set for the externals.
> For me, this is the main point missing in SVN and a blocker for any use,
> as a tagged version may never be restored and the quality department
> will say to you: you are not able to reproduce the source code.
>

I assume your externals property doesn't specify a PEG revision (see the
SVN book [1]). If you did, then the external would update to that
particular peg revision, otherwise the peg revision defaults to HEAD.

In /trunk it is probably tempting to have the externals tracking HEAD. But
when you tag a release it should be part of your process to freeze all
externals to a certain point in time (either to switch them to a specific
tag or pegging them to a revision). That way you can easily go back in time
to and restore the complete working copy. The TortoiseSVN repository [2] is
using this for all release tags, they are updating all externals to the
desired tag in the external repository.

As for your use case, I can see a point in having the externals definition
default to the same revision as the rest of the working copy (since they
are in the same repository and share the same revision number sequence).
But I feel the same way as C. Michael Pilato in his first comment: "The
disparity between behaviors for externals that happen to point to the
same repository and those that point to a different repository bothers
me.". It will for sure make things more difficult to explain if externals
pointing to another repository default to HEAD while intra-repository
externals point to "same revision" (that would be BASE, I think).

Kind regards,
Daniel


[1] https://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
[2] https://osdn.net/projects/tortoisesvn/scm/svn/