Checkout through link ignores rev parameter

[Dalton, Bill (GE Energy Connections)]

We have projects which share some of the files in the subversion folders but not all. So, those projects put their files into separate folders. One of the pairs of folders contains the actual files. The other folder of the pair has subversion links which point to the actual files in the other folder. This strategy seems to work with only one very important exception. When the folder with the links is checked out, the actual files always return the HEAD version, ignoring the "rev=" parameter.

Specifically, there are two folder in Subversion whose paths are "trunk/firmware/cpu_fw/dia" and "trunk/firmware/cpu_fw_vx7/dia". Most of the files in the cpu_fw_vx7/dia folder (that is, all of the shared files) are links which point to the corresponding file in the cpu_fw/dia folder. If the cpu_fw_vx7/dia folder is updated with a "svn update -r 17905 -non-interactive -force svnRepos/trunk/firmware/cpu_fw_vx7/dia" command, it will always fetch the HEAD revision, instead of the 17905 revision.

[Eric Johnson]

What version of the Subversion client & server are you using?

Eric

On Mon, Jan 23, 2017 at 10:54 AM, Dalton, Bill (GE Energy Connections) <

Post by Dalton, Bill (GE Energy Connections)
We have projects which share some of the files in the subversion folders
but not all. So, those projects put their files into separate folders.
One of the pairs of folders contains the actual files. The other folder of
the pair has subversion links which point to the actual files in the other
folder. This strategy seems to work with only one very important
exception. When the folder with the links is checked out, the actual
files always return the HEAD version, ignoring the “rev=” parameter.
Specifically, there are two folder in Subversion whose paths are
“trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most of
the files in the cpu_fw_vx7/dia folder (that is, all of the shared files)
are links which point to the corresponding file in the cpu_fw/dia folder.
If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905
–non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command,
it will always fetch the HEAD revision, instead of the 17905 revision.

[Dalton, Bill (GE Energy Connections)]

Our Subversion server is 1.9.2. Almost all of our agents are 1.9.4. A couple of the agents are 1.7.9


From: Eric Johnson [mailto:***@tibco.com]
Sent: Tuesday, January 24, 2017 4:39 PM
To: Dalton, Bill (GE Energy Connections) <***@ge.com>
Cc: ***@subversion.apache.org; Hannold, Bill (GE Energy Connections) <***@ge.com>
Subject: EXT: Re: Checkout through link ignores rev parameter

What version of the Subversion client & server are you using?

Eric

On Mon, Jan 23, 2017 at 10:54 AM, Dalton, Bill (GE Energy Connections) <***@ge.com<mailto:***@ge.com>> wrote:
We have projects which share some of the files in the subversion folders but not all. So, those projects put their files into separate folders. One of the pairs of folders contains the actual files. The other folder of the pair has subversion links which point to the actual files in the other folder. This strategy seems to work with only one very important exception. When the folder with the links is checked out, the actual files always return the HEAD version, ignoring the “rev=” parameter.

Specifically, there are two folder in Subversion whose paths are “trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most of the files in the cpu_fw_vx7/dia folder (that is, all of the shared files) are links which point to the corresponding file in the cpu_fw/dia folder. If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905 –non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command, it will always fetch the HEAD revision, instead of the 17905 revision.

[Johan Corveleyn]

On Mon, Jan 23, 2017 at 7:54 PM, Dalton, Bill (GE Energy Connections)

Post by Dalton, Bill (GE Energy Connections)
We have projects which share some of the files in the subversion folders but
not all. So, those projects put their files into separate folders. One of
the pairs of folders contains the actual files. The other folder of the
pair has subversion links which point to the actual files in the other
folder. This strategy seems to work with only one very important exception.
When the folder with the links is checked out, the actual files always
return the HEAD version, ignoring the “rev=” parameter.
Specifically, there are two folder in Subversion whose paths are
“trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most of
the files in the cpu_fw_vx7/dia folder (that is, all of the shared files)
are links which point to the corresponding file in the cpu_fw/dia folder.
If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905
–non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia” command, it
will always fetch the HEAD revision, instead of the 17905 revision.

Hi Bill,

There is no such thing as "Subversion links". I'm assuming you mean
"externals" (more specifically "file externals", if I understand
correctly). Anyway, I think what you're seeing is this bug (which is
very old):

https://issues.apache.org/jira/browse/SVN-2516 (--revision option is
not forwarded to svn:externals references)

The issue was last updated in 2015, with a reference to a mail thread
on the dev-list, containing a design / specs discussion (which
unfortunately seems to have stranded):

http://svn.haxx.se/dev/archive-2015-08/0179.shtml

[Dalton, Bill (GE Energy Connections)]

Johan,

Thanks for your response.

When I saw this description, I thought, "Oh yes. That's our problem." However, I think the thread I was looking at said it was fixed in 1.6. Our Subversion server is 1.9.2. Almost all of our agents are 1.9.4. A couple of the agents are 1.7.9. So, it doesn't seem to be the same problem. Or maybe there is a path to get to that failure that wasn't fixed.

Sorry about the terminology. I'm not familiar with how these links are implemented. I have assumed that they were just Unix links. I know that what looks like a file is actually a pointer to another location which contains the actual file.

Bill

-----Original Message-----
From: Johan Corveleyn [mailto:***@gmail.com]
Sent: Tuesday, January 24, 2017 5:20 PM
To: Dalton, Bill (GE Energy Connections) <***@ge.com>
Cc: ***@subversion.apache.org; Hannold, Bill (GE Energy Connections) <***@ge.com>
Subject: EXT: Re: Checkout through link ignores rev parameter

Post by Dalton, Bill (GE Energy Connections)
We have projects which share some of the files in the subversion
folders but not all. So, those projects put their files into separate
folders. One of the pairs of folders contains the actual files. The
other folder of the pair has subversion links which point to the
actual files in the other folder. This strategy seems to work with only one very important exception.
When the folder with the links is checked out, the actual files
always return the HEAD version, ignoring the “rev=” parameter.
Specifically, there are two folder in Subversion whose paths are
“trunk/firmware/cpu_fw/dia” and “trunk/firmware/cpu_fw_vx7/dia”. Most
of the files in the cpu_fw_vx7/dia folder (that is, all of the shared
files) are links which point to the corresponding file in the cpu_fw/dia folder.
If the cpu_fw_vx7/dia folder is updated with a “svn update -r 17905
–non-interactive –force svnRepos/trunk/firmware/cpu_fw_vx7/dia”
command, it will always fetch the HEAD revision, instead of the 17905 revision.

Hi Bill,

There is no such thing as "Subversion links". I'm assuming you mean "externals" (more specifically "file externals", if I understand correctly). Anyway, I think what you're seeing is this bug (which is very old):

https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SVN-2D2516&d=DQIFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=yvIDsFuVzfRgZstZ_Ob6IPM_fQ2qEpHAciKWAEBRKA4&m=-0qjOQDBBuIUbZm-A_V26RoFu154y2XSJeQcuzXre08&s=x63Xj33NLxhT4bGGC8mF51wJaBo54vV0DeQIURY9DKk&e= (--revision option is not forwarded to svn:externals references)

The issue was last updated in 2015, with a reference to a mail thread on the dev-list, containing a design / specs discussion (which unfortunately seems to have stranded):

https://urldefense.proofpoint.com/v2/url?u=http-3A__svn.haxx.se_dev_archive-2D2015-2D08_0179.shtml&d=DQIFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=yvIDsFuVzfRgZstZ_Ob6IPM_fQ2qEpHAciKWAEBRKA4&m=-0qjOQDBBuIUbZm-A_V26RoFu154y2XSJeQcuzXre08&s=MNyiXuGZBdt0ftxSTT8XKwEdGsw0DvxMONMbhq_x120&e=

[Johan Corveleyn]

On Wed, Jan 25, 2017 at 2:23 PM, Dalton, Bill (GE Energy Connections)

Post by Dalton, Bill (GE Energy Connections)
Johan,
Thanks for your response.
When I saw this description, I thought, "Oh yes. That's our problem." However, I think the thread I was looking at said it was fixed in 1.6. Our Subversion server is 1.9.2. Almost all of our agents are 1.9.4. A couple of the agents are 1.7.9. So, it doesn't seem to be the same problem. Or maybe there is a path to get to that failure that wasn't fixed.
Sorry about the terminology. I'm not familiar with how these links are implemented. I have assumed that they were just Unix links. I know that what looks like a file is actually a pointer to another location which contains the actual file.
Bill

No, the issue I referred you to, SVN-2516 [1] is not fixed, not even
in trunk. It's status in JIRA is "open", and I think that's correct.
The mail thread linked from the issue also ends without a conclusion
(there doesn't seem to be a definitive consensus on how it should
behave, and whether or not the new behaviour would need an option
flag, or if it would become the default). I don't see any mention of a
fix being in 1.6.

Also: externals are quite different from unix symlinks. For starters,
they are a working-copy-only thing ... the server doesn't know /
understand the link. It only sees a property ("svn:externals"), but it
doesn't interpret nor understand this property. It's just the svn
client which does some extra work when it sees such an svn:externals
property, by pulling in the extra items from the pointed-to repository
location into the working copy.

[1] https://issues.apache.org/jira/browse/SVN-2516

[Dalton, Bill (GE Energy Connections)]

Thanks very much Johan. This clears up a lot.

We know how we would want it to work. I'm guessing that if we need it "fixed", that we would need to get the souce, make our fix, and build our own version? That has the advantage of giving us control on how it works for us, but makes updating to future versions complicated and risky.

-----Original Message-----
From: Johan Corveleyn [mailto:***@gmail.com]
Sent: Wednesday, January 25, 2017 10:33 AM
To: Dalton, Bill (GE Energy Connections) <***@ge.com>
Cc: ***@subversion.apache.org; Hannold, Bill (GE Energy Connections) <***@ge.com>; Hawker, Jason (GE Energy Connections) <***@ge.com>
Subject: EXT: Re: Checkout through link ignores rev parameter

Post by Dalton, Bill (GE Energy Connections)
Johan,
Thanks for your response.
When I saw this description, I thought, "Oh yes. That's our problem." However, I think the thread I was looking at said it was fixed in 1.6. Our Subversion server is 1.9.2. Almost all of our agents are 1.9.4. A couple of the agents are 1.7.9. So, it doesn't seem to be the same problem. Or maybe there is a path to get to that failure that wasn't fixed.
Sorry about the terminology. I'm not familiar with how these links are implemented. I have assumed that they were just Unix links. I know that what looks like a file is actually a pointer to another location which contains the actual file.
Bill

No, the issue I referred you to, SVN-2516 [1] is not fixed, not even in trunk. It's status in JIRA is "open", and I think that's correct.
The mail thread linked from the issue also ends without a conclusion (there doesn't seem to be a definitive consensus on how it should behave, and whether or not the new behaviour would need an option flag, or if it would become the default). I don't see any mention of a fix being in 1.6.

Also: externals are quite different from unix symlinks. For starters, they are a working-copy-only thing ... the server doesn't know / understand the link. It only sees a property ("svn:externals"), but it doesn't interpret nor understand this property. It's just the svn client which does some extra work when it sees such an svn:externals property, by pulling in the extra items from the pointed-to repository location into the working copy.

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SVN-2D2516&d=DQIFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=yvIDsFuVzfRgZstZ_Ob6IPM_fQ2qEpHAciKWAEBRKA4&m=OjI4KWOlP8rGDQtrJKCFFx3f2vQx0In8f-bDqoYN3Hg&s=D3CKhlT2ScQ30LG4Ab8PCMFaKzTjuCGDtRbr

[Ryan Schmidt]

Post by Dalton, Bill (GE Energy Connections)
We know how we would want it to work. I'm guessing that if we need it "fixed", that we would need to get the souce, make our fix, and build our own version? That has the advantage of giving us control on how it works for us, but makes updating to future versions complicated and risky.

If you know how to fix a Subversion bug and contribute that fix, I'm sure the Subversion developers would be appreciative.

[Johan Corveleyn]

On Wed, Jan 25, 2017 at 9:16 PM, Ryan Schmidt

Post by Ryan Schmidt

Post by Dalton, Bill (GE Energy Connections)
We know how we would want it to work. I'm guessing that if we need it "fixed", that we would need to get the souce, make our fix, and build our own version? That has the advantage of giving us control on how it works for us, but makes updating to future versions complicated and risky.

If you know how to fix a Subversion bug and contribute that fix, I'm sure the Subversion developers would be appreciative.

Yes, absolutely. And I think a solution is definitely possible, if
someone is prepared to spend time on it. In this case, I think it's
best to start from that discussion thread from 2015 [1], try to
summarize where it stranded, and bring it up again on the
***@subversion.apache.org mailinglist with your view on how it should
work. We can then try finding a consensus in the community on the
specs.

Apart from discussing how it should behave (which is the first step),
you might want to take a look at Subversions Community Guide [2].

[1] http://svn.haxx.se/dev/archive-2015-08/0179.shtml
[2] http://subversion.apache.org/docs/community-guide/