You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by leo <le...@gmx.net> on 2005/06/28 16:11:20 UTC
svn:externals and revisions
I want to use svn:externals to get the required modules into the main
project. when svn:externals points to a tag of the module it works fine.
but when svn:externals points to the trunk of the module, I have some
problems.
when working on the head of both the main project and the module all is ok.
but when I
want to update the project to a previous revision, I still get the head
revision of the module. I expected to get the specified revision for both
main project and the module.
I know that I can specify the revision in the svn:externals property but
this is not
possible for already commited versions.
Can someone explain this behaviour or give me hints in using svn:externals?
-leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
Norbert Unterberg <nu...@gmail.com> writes:
> 2005/6/28, John Peacock <jp...@rowman.com>:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely that
> > the same rev number has no correlation there.
>
> This issue is coming up again and again. Are there any plans about a
> new property that is designed for this kind of requests, like
> "svn:internals" or a smarter "svn:externals" property that would
> accepts relative paths inside the same repository (so they survive
> branching and tagging)?
There is an open issue (#1336) about svn:externals accepting relative
URLs, yes. Great idea, in my opinion.
But that is entirely independent from the question of how revisions
should behave. Even if a relative URL is used, there is no reason to
assume that the revision of the external working copy should
implicitly track the revision of the "main" working copy. That said,
I would not strongly oppose adding a new "EXT" revision keyword (like
"HEAD", "PREV", ...) which means, "Use the revision of the directory
whose svn:externals property is controlling this working copy as an
external" (and of course, is only valid when used in externals
definitions. If folks use -rEXT with externals that aren't in the
same repository, they'll just (likely) get completely broken behavior,
of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
7/7/05, Molle Bestefich <mo...@gmail.com> wrote:
> 6/28/05, Norbert Unterberg <nu...@gmail.com> wrote:
> > This issue is coming up again and again. Are there any plans about a
> > new property that is designed for this kind of requests, like
> > "svn:internals" or a smarter "svn:externals" property that would
> OMG, it would be wonderful to have this fixed.
>
> I imagine that there are actually a whole lot more people that use
> svn:externals for references to framework / core files internally in
> the repository than there is people using it for it's original
> purpose? I've seen a lot of people use svn:external for internal refs
> over on TSVN, but noone that use it to reference external
> repositories. Am I completely wrong?
>
> We're getting bit by the svn:external design on a daily basis, and I
> imagine others are too... Here's some of the problems we've seen..
>
> Problems:
>
> - When tagging a project, svn:external'd files inside the tags
> continue to update to HEAD (already mentioned) :-(..
>
> - When changing the server name of the Subversion server, all of the
> svn:external tags go dead :-(..
- In the same ball park: We're effectively locked with the SVN
access method that our current setup has - if we change it, all of the
external references will die :-O..
>
> - When switching a WC from one URL to another, framework files are not
> updated while everything else is. You have to do an explicit 'svn up'
> to get the framework files updated :-(..
>
> - When updating a WC, a long list of "External: blah blah" lines are
> output, which obscures the view and "hides" the interesting stuff, eg.
> files that have been updated :-(..
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
6/28/05, Norbert Unterberg <nu...@gmail.com> wrote:
> 2005/6/28, John Peacock <jp...@rowman.com>:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely that
> > the same rev number has no correlation there.
>
> This issue is coming up again and again. Are there any plans about a
> new property that is designed for this kind of requests, like
> "svn:internals" or a smarter "svn:externals" property that would
> accepts relative paths inside the same repository (so they survive
> branching and tagging)? It is not the first time that I would like
> something that fits the CVS virtual modules (were they called that
> way?) more closely than an svn:externals...
OMG, it would be wonderful to have this fixed.
I imagine that there are actually a whole lot more people that use
svn:externals for references to framework / core files internally in
the repository than there is people using it for it's original
purpose? I've seen a lot of people use svn:external for internal refs
over on TSVN, but noone that use it to reference external
repositories. Am I completely wrong?
We're getting bit by the svn:external design on a daily basis, and I
imagine others are too... Here's some of the problems we've seen..
Problems:
- When tagging a project, svn:external'd files inside the tags
continue to update to HEAD (already mentioned) :-(..
- When changing the server name of the Subversion server, all of the
svn:external tags go dead :-(..
- When switching a WC from one URL to another, framework files are not
updated while everything else is. You have to do an explicit 'svn up'
to get the framework files updated :-(..
- When updating a WC, a long list of "External: blah blah" lines are
output, which obscures the view and "hides" the interesting stuff, eg.
files that have been updated :-(..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
6/28/05, Norbert Unterberg <nu...@gmail.com> wrote:
> 2005/6/28, John Peacock <jp...@rowman.com>:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely that
> > the same rev number has no correlation there.
>
> This issue is coming up again and again. Are there any plans about a
> new property that is designed for this kind of requests, like
> "svn:internals" or a smarter "svn:externals" property that would
> accepts relative paths inside the same repository (so they survive
> branching and tagging)? It is not the first time that I would like
> something that fits the CVS virtual modules (were they called that
> way?) more closely than an svn:externals...
OMG, it would be wonderful to have this fixed.
I imagine that there are actually a whole lot more people that use
svn:externals for references to framework / core files internally in
the repository than there is people using it for it's original
purpose? I've seen a lot of people use svn:external for internal refs
over on TSVN, but noone that use it to reference external
repositories. Am I completely wrong?
We're getting bit by the svn:external design on a daily basis, and I
imagine others are too... Here's some of the problems we've seen..
Problems:
- When tagging a project, svn:external'd files inside the tags
continue to update to HEAD (already mentioned) :-(..
- When changing the server name of the Subversion server, all of the
svn:external tags go dead :-(..
- When switching a WC from one URL to another, framework files are not
updated while everything else is. You have to do an explicit 'svn up'
to get the framework files updated :-(..
- When updating a WC, a long list of "External: blah blah" lines are
output, which obscures the view and "hides" the interesting stuff, eg.
files that have been updated :-(..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
Norbert Unterberg <nu...@gmail.com> writes:
> 2005/6/28, John Peacock <jp...@rowman.com>:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely that
> > the same rev number has no correlation there.
>
> This issue is coming up again and again. Are there any plans about a
> new property that is designed for this kind of requests, like
> "svn:internals" or a smarter "svn:externals" property that would
> accepts relative paths inside the same repository (so they survive
> branching and tagging)?
There is an open issue (#1336) about svn:externals accepting relative
URLs, yes. Great idea, in my opinion.
But that is entirely independent from the question of how revisions
should behave. Even if a relative URL is used, there is no reason to
assume that the revision of the external working copy should
implicitly track the revision of the "main" working copy. That said,
I would not strongly oppose adding a new "EXT" revision keyword (like
"HEAD", "PREV", ...) which means, "Use the revision of the directory
whose svn:externals property is controlling this working copy as an
external" (and of course, is only valid when used in externals
definitions. If folks use -rEXT with externals that aren't in the
same repository, they'll just (likely) get completely broken behavior,
of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/6/28, John Peacock <jp...@rowman.com>:
> Ben Collins-Sussman wrote:
> > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > updates the working copy to revision X, but updates the externals to HEAD?
>
> What other choice would you have Subversion make? Externals can point
> at a completely different repository, so there it is highly likely that
> the same rev number has no correlation there.
This issue is coming up again and again. Are there any plans about a
new property that is designed for this kind of requests, like
"svn:internals" or a smarter "svn:externals" property that would
accepts relative paths inside the same repository (so they survive
branching and tagging)? It is not the first time that I would like
something that fits the CVS virtual modules (were they called that
way?) more closely than an svn:externals...
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> Lorenz wrote:
[...]
> No reason - the poster describes this as a bug when creating tags.
Hm, that wasn't the *original* poster.
Duh, sorry.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-07-07 at 16:30 +0200, Molle Bestefich wrote:
[...]
Please do not respond to four messages in the same thread in rapid
succession. Read the whole thread, think carefully about what you have
to say, pick a message to reply to, and lay out your thoughts.
Occasionally it might make sense to separately reply to as many as two
messages in a thread. But the dev list is very high-traffic, and it's
very disruptive to have people multiplying this traffic by responding to
nearly every message in a thread.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
7/7/05, Lorenz <lo...@yahoo.com> wrote:
> > [...] In fact, a "best practice" for proper use of externals would
> > demand that all externals definitions specify a particular revision [...]
>
> perhaps attaching the actual revision of the svn:external on commit
> (only if there is not a revision attached already), while leaving the
> svn:external setting in the wc unchanged would solve the problem.
>
> When checking out a revision later you then would always get the
> svn:external@rev used a the time of the commit.
>
> Updating such a svn:external to head or any other rev would require
> to change the property first.
> What do you think?
Useful behaviour, if you are thinking along the lines that people
actually use svn:externals for what it was originally intended for.
If you look at what the poster (and mostly everyone else, I imagine?)
are using svn:externals for, it's a horrible suggestion that would
only make things worse :-).
> But for what reason someone would check out an old rev and want the
> the svn:external to be at it's head rev?
No reason - the poster describes this as a bug when creating tags.
The "bug" (?) occurs because he's using svn:externals for something
else than it was designed to do - as are the rest of us..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Lorenz <lo...@yahoo.com>.
Hi all,
> [...] In fact, a "best practice" for proper use of externals would
> demand that all externals definitions specify a particular revision [...]
perhaps attaching the actual revision of the svn:external on commit
(only if there is not a revision attached already), while leaving the
svn:external setting in the wc unchanged would solve the problem.
When checking out a revision later you then would always get the
svn:external@rev used a the time of the commit.
Updating such a svn:external to head or any other rev would require
to change the property first.
But for what reason someone would check out an old rev and want the
the svn:external to be at it's head rev?
I can only think of a branch started from an older rev. In this case
changing the property wouldn't hurt.
What do you think?
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Andy Peters <de...@latke.net>.
John Peacock writes:
> C. Michael Pilato wrote:
>> kfogel@collab.net writes:
>>
>>
>>> Couldn't the svn:externals code detect when an external subdir is from
>>> the same repository as its parent, so that
>>
>> It could, but there's reason to assume that just because two projects
> ^no
>> share a repository that they also share the likes of API compatibility
>> and such.
>
> ...
>
>> Rather than introduce conditional behavior, let's keep things simple and
>> educate the users.
>
> Yes, document best practices (using explicit revisions or branches for
> svn:externals) rather than make the code too smart for its own good...
Seems to me that you should always use a tagged (or otherwise
known-not-to-change) external "module" ... this way, your builds of your own
code aren't done against a moving target.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
>
>>Couldn't the svn:externals code detect when an external subdir is from
>>the same repository as its parent, so that
>
> It could, but there's reason to assume that just because two projects
^no
> share a repository that they also share the likes of API compatibility
> and such.
...
> Rather than introduce conditional behavior, let's keep things simple and educate the users.
Yes, document best practices (using explicit revisions or branches for
svn:externals) rather than make the code too smart for its own good...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by John Peacock <jp...@rowman.com>.
C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
>
>>Couldn't the svn:externals code detect when an external subdir is from
>>the same repository as its parent, so that
>
> It could, but there's reason to assume that just because two projects
^no
> share a repository that they also share the likes of API compatibility
> and such.
...
> Rather than introduce conditional behavior, let's keep things simple and educate the users.
Yes, document best practices (using explicit revisions or branches for
svn:externals) rather than make the code too smart for its own good...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Romain Prévost <pr...@gmail.com>.
> Since everybody's already abusing 'svn:externals', a wiser choice
> would be to introduce a 'svn:internals' with the desired behaviour,
> eg. one that updates the files like the users are expecting.
>
> Another Good Thing (TM) that this would bring to the table would be
> that 'svn cp' could have an option named '--pin-internals' that users
> could use when tagging a project, so that shared files remain tagged
> (instead of following HEAD ?!).
This is on my wishlist too :) But anyway, I've seen several SCM
handling quite poorly this kind of issues.
--
Romain Prévost
Epitech promotion 2007
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
Molle Bestefich wrote:
> C. Michael Pilato wrote:
> > Rather than introduce conditional behavior,
> > let's keep things simple and educate the users.
>
> Since everybody's already abusing 'svn:externals', a wiser choice
> would be to introduce a 'svn:internals' with the desired behaviour,
Upon re-reading, I see that I might have phrased the above wrong.
"wiser choice" sounds like the proposal is an alternative, while it's
exactly the opposite - it's a way to keep things simple and steer away
from conditional behaviour, just as you wanted.
Apologies, hope I'm not angrying up anybody's blood (like I usually do) :-)..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Romain Prévost <pr...@gmail.com>.
> Since everybody's already abusing 'svn:externals', a wiser choice
> would be to introduce a 'svn:internals' with the desired behaviour,
> eg. one that updates the files like the users are expecting.
>
> Another Good Thing (TM) that this would bring to the table would be
> that 'svn cp' could have an option named '--pin-internals' that users
> could use when tagging a project, so that shared files remain tagged
> (instead of following HEAD ?!).
This is on my wishlist too :) But anyway, I've seen several SCM
handling quite poorly this kind of issues.
--
Romain Prévost
Epitech promotion 2007
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
> > Couldn't the svn:externals code detect when an external subdir is from
> > the same repository as its parent, so that
> >
> > $ svn up -rN
> >
> > would update both the parent and the svn:external subdir to N in that
> > case? And in the not-same case, it would update the parent to N and
> > the external to HEAD, as it does now, of course.
>
> It could, but there's reason to assume that just because two projects
> share a repository that they also share the likes of API compatibility
> and such. That is, just because the APR team tweaks some APIs in
> their /trunk doesn't mean that the Apache HTTP Server guys have
> changed HTTP Server to track those API changes yet.
Might be true for the Apache project, but there's just as many
projects where the opposite is true. We have some of those.
> Rather than introduce conditional behavior,
> let's keep things simple and educate the users.
Since everybody's already abusing 'svn:externals', a wiser choice
would be to introduce a 'svn:internals' with the desired behaviour,
eg. one that updates the files like the users are expecting.
Another Good Thing (TM) that this would bring to the table would be
that 'svn cp' could have an option named '--pin-internals' that users
could use when tagging a project, so that shared files remain tagged
(instead of following HEAD ?!).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Molle Bestefich <mo...@gmail.com>.
C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
> > Couldn't the svn:externals code detect when an external subdir is from
> > the same repository as its parent, so that
> >
> > $ svn up -rN
> >
> > would update both the parent and the svn:external subdir to N in that
> > case? And in the not-same case, it would update the parent to N and
> > the external to HEAD, as it does now, of course.
>
> It could, but there's reason to assume that just because two projects
> share a repository that they also share the likes of API compatibility
> and such. That is, just because the APR team tweaks some APIs in
> their /trunk doesn't mean that the Apache HTTP Server guys have
> changed HTTP Server to track those API changes yet.
Might be true for the Apache project, but there's just as many
projects where the opposite is true. We have some of those.
> Rather than introduce conditional behavior,
> let's keep things simple and educate the users.
Since everybody's already abusing 'svn:externals', a wiser choice
would be to introduce a 'svn:internals' with the desired behaviour,
eg. one that updates the files like the users are expecting.
Another Good Thing (TM) that this would bring to the table would be
that 'svn cp' could have an option named '--pin-internals' that users
could use when tagging a project, so that shared files remain tagged
(instead of following HEAD ?!).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> Couldn't the svn:externals code detect when an external subdir is from
> the same repository as its parent, so that
>
> $ svn up -rN
>
> would update both the parent and the svn:external subdir to N in that
> case? And in the not-same case, it would update the parent to N and
> the external to HEAD, as it does now, of course.
It could, but there's reason to assume that just because two projects
share a repository that they also share the likes of API compatibility
and such. That is, just because the APR team tweaks some APIs in
their /trunk doesn't mean that the Apache HTTP Server guys have
changed HTTP Server to track those API changes yet. Rather than
introduce conditional behavior, let's keep things simple and educate
the users.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> Couldn't the svn:externals code detect when an external subdir is from
> the same repository as its parent, so that
>
> $ svn up -rN
>
> would update both the parent and the svn:external subdir to N in that
> case? And in the not-same case, it would update the parent to N and
> the external to HEAD, as it does now, of course.
It could, but there's reason to assume that just because two projects
share a repository that they also share the likes of API compatibility
and such. That is, just because the APR team tweaks some APIs in
their /trunk doesn't mean that the Apache HTTP Server guys have
changed HTTP Server to track those API changes yet. Rather than
introduce conditional behavior, let's keep things simple and educate
the users.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> John Peacock <jp...@rowman.com> writes:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to
> > > HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely
> > that the same rev number has no correlation there. This could be
> > added as a FAQ item (cd into the externals directory and update to the
> > appropriate backrev if desired).
>
> Correct. In fact, a "best practice" for proper use of externals would
> demand that all externals definitions specify a particular revision so
> the a project can a) choose more intelligently when to "upgrade" to a
> newer snapshot of the external thing, and b) so that the version
> history of the main and external repositories can be more tightly
> coupled, allowing for backdates which are guaranteed to produce
> accurate results.
>
> I'll make a note to add such a thing to the Subversion book.
Couldn't the svn:externals code detect when an external subdir is from
the same repository as its parent, so that
$ svn up -rN
would update both the parent and the svn:external subdir to N in that
case? And in the not-same case, it would update the parent to N and
the external to HEAD, as it does now, of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> John Peacock <jp...@rowman.com> writes:
> > Ben Collins-Sussman wrote:
> > > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > > updates the working copy to revision X, but updates the externals to
> > > HEAD?
> >
> > What other choice would you have Subversion make? Externals can point
> > at a completely different repository, so there it is highly likely
> > that the same rev number has no correlation there. This could be
> > added as a FAQ item (cd into the externals directory and update to the
> > appropriate backrev if desired).
>
> Correct. In fact, a "best practice" for proper use of externals would
> demand that all externals definitions specify a particular revision so
> the a project can a) choose more intelligently when to "upgrade" to a
> newer snapshot of the external thing, and b) so that the version
> history of the main and external repositories can be more tightly
> coupled, allowing for backdates which are guaranteed to produce
> accurate results.
>
> I'll make a note to add such a thing to the Subversion book.
Couldn't the svn:externals code detect when an external subdir is from
the same repository as its parent, so that
$ svn up -rN
would update both the parent and the svn:external subdir to N in that
case? And in the not-same case, it would update the parent to N and
the external to HEAD, as it does now, of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> Ben Collins-Sussman wrote:
> > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > updates the working copy to revision X, but updates the externals to
> > HEAD?
>
> What other choice would you have Subversion make? Externals can point
> at a completely different repository, so there it is highly likely
> that the same rev number has no correlation there. This could be
> added as a FAQ item (cd into the externals directory and update to the
> appropriate backrev if desired).
Correct. In fact, a "best practice" for proper use of externals would
demand that all externals definitions specify a particular revision so
the a project can a) choose more intelligently when to "upgrade" to a
newer snapshot of the external thing, and b) so that the version
history of the main and external repositories can be more tightly
coupled, allowing for backdates which are guaranteed to produce
accurate results.
I'll make a note to add such a thing to the Subversion book.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Norbert Unterberg <nu...@gmail.com>.
2005/6/28, John Peacock <jp...@rowman.com>:
> Ben Collins-Sussman wrote:
> > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > updates the working copy to revision X, but updates the externals to HEAD?
>
> What other choice would you have Subversion make? Externals can point
> at a completely different repository, so there it is highly likely that
> the same rev number has no correlation there.
This issue is coming up again and again. Are there any plans about a
new property that is designed for this kind of requests, like
"svn:internals" or a smarter "svn:externals" property that would
accepts relative paths inside the same repository (so they survive
branching and tagging)? It is not the first time that I would like
something that fits the CVS virtual modules (were they called that
way?) more closely than an svn:externals...
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> Ben Collins-Sussman wrote:
> > Hm, this might be a bug. What you're saying is that 'svn up -r X'
> > updates the working copy to revision X, but updates the externals to
> > HEAD?
>
> What other choice would you have Subversion make? Externals can point
> at a completely different repository, so there it is highly likely
> that the same rev number has no correlation there. This could be
> added as a FAQ item (cd into the externals directory and update to the
> appropriate backrev if desired).
Correct. In fact, a "best practice" for proper use of externals would
demand that all externals definitions specify a particular revision so
the a project can a) choose more intelligently when to "upgrade" to a
newer snapshot of the external thing, and b) so that the version
history of the main and external repositories can be more tightly
coupled, allowing for backdates which are guaranteed to produce
accurate results.
I'll make a note to add such a thing to the Subversion book.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Hm, this might be a bug. What you're saying is that 'svn up -r X'
> updates the working copy to revision X, but updates the externals to HEAD?
What other choice would you have Subversion make? Externals can point
at a completely different repository, so there it is highly likely that
the same rev number has no correlation there. This could be added as a
FAQ item (cd into the externals directory and update to the appropriate
backrev if desired).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> Hm, this might be a bug. What you're saying is that 'svn up -r X'
> updates the working copy to revision X, but updates the externals to HEAD?
What other choice would you have Subversion make? Externals can point
at a completely different repository, so there it is highly likely that
the same rev number has no correlation there. This could be added as a
FAQ item (cd into the externals directory and update to the appropriate
backrev if desired).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Ben Collins-Sussman <su...@collab.net>.
[crossposting to dev@]
On Jun 28, 2005, at 11:11 AM, leo wrote:
> I want to use svn:externals to get the required modules into the main
> project. when svn:externals points to a tag of the module it works
> fine.
>
> but when svn:externals points to the trunk of the module, I have some
> problems.
> when working on the head of both the main project and the module
> all is ok.
> but when I
> want to update the project to a previous revision, I still get the
> head
> revision of the module. I expected to get the specified revision
> for both
> main project and the module.
>
> I know that I can specify the revision in the svn:externals
> property but
> this is not
> possible for already commited versions.
>
> Can someone explain this behaviour or give me hints in using
> svn:externals?
>
Hm, this might be a bug. What you're saying is that 'svn up -r X'
updates the working copy to revision X, but updates the externals to
HEAD?
Developers, should we file this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn:externals and revisions
Posted by Ben Collins-Sussman <su...@collab.net>.
[crossposting to dev@]
On Jun 28, 2005, at 11:11 AM, leo wrote:
> I want to use svn:externals to get the required modules into the main
> project. when svn:externals points to a tag of the module it works
> fine.
>
> but when svn:externals points to the trunk of the module, I have some
> problems.
> when working on the head of both the main project and the module
> all is ok.
> but when I
> want to update the project to a previous revision, I still get the
> head
> revision of the module. I expected to get the specified revision
> for both
> main project and the module.
>
> I know that I can specify the revision in the svn:externals
> property but
> this is not
> possible for already commited versions.
>
> Can someone explain this behaviour or give me hints in using
> svn:externals?
>
Hm, this might be a bug. What you're saying is that 'svn up -r X'
updates the working copy to revision X, but updates the externals to
HEAD?
Developers, should we file this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org