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

[Harald Oehlmann]

( 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.

Sorry.
Thank you for all,
Harald

[Daniel Sahlberg]

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/

 

[Harald Oehlmann]

Am 28.09.2022 um 11:43 schrieb Daniel Sahlberg:
> Den ons 28 sep. 2022 kl 10:29 skrev Harald Oehlmann

> <harald....@elmicron.de <mailto:harald....@elmicron.de>>:

> <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

[Daniel Sahlberg]

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

[Harald Oehlmann]

Am 28.09.2022 um 12:59 schrieb Daniel Sahlberg:
> Den ons 28 sep. 2022 kl 11:52 skrev Harald Oehlmann

> <harald....@elmicron.de <mailto:harald....@elmicron.de>>:

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

> <mailto:harald....@elmicron.de

thank you for the answer. I would have answered like you. I am in the
TCL open source community and we use fossil scm.

I will unfortunately not contribute to subversion code. I understand,
that that would be the only logical step and it is ok to ask for it.
I personally hate GIT, but most open source projects go there and I have
to use it each day.
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 know, that there are externals with version number in SVN. I use that
a lot. But it hurts in the workflow, when I just want "the latest".
Frankly, I prefer branches, in this case, as I can modify the extern
target at one place, even if there are hunreds of extern pointing to it.

Thank you again and take care,
Harald

[Alfred von Campe]

> On Sep 28, 2022, at 7:10, Harald Oehlmann <harald....@elmicron.de> 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

[Harald Oehlmann]

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.