You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Finley, Stephen" <st...@fmr.com> on 2007/02/05 16:15:56 UTC
Problems with externals
Hi all
I am not sure if I am missing something with externals or not.
I set the properties on a directory to be an external to a specific
revision. If I do an update at the top level I get the correct code, but
if I do an update on the external directory I get the latest code for
those files not the revision. I believe this is an error in subversions
handling of externals.
I hope what I am saying makes sense.
Example.
Myproject has property set to use external revision 5 of
myproject2/common-files in directory common-files
So you would end up with the directory
/myproject/common-files
If I do any update on the myproject directory it would get the correct
version of the files, but if I went and did an update on the
common-files directory it would update to the latest version of these
files in /myprojects/common-files not version 5.
Thank for any help
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with externals
Posted by Lorenz <lo...@yahoo.com>.
Finley, Stephen wrote:
>I set the properties on a directory to be an external to a specific
>revision. If I do an update at the top level I get the correct code, but
>if I do an update on the external directory I get the latest code for
>those files not the revision. I believe this is an error in subversions
>handling of externals.
>[...]
>Myproject has property set to use external revision 5 of
>myproject2/common-files in directory common-files
That's not a bug, it's a feature 8-)
This behaviour is by design. the svn:externals property is only
relevant to the wc it is set on (myproject2), and only in case of svn
co/up.
The subfolder (common-files) on the other hand is a wc of its on,
that knows nothing about the way it was created.
So an svn co/up on myproject2 knows to pull in revision 5 of
common-files, but an update on common-files itself will get you HEAD.
As you want it to stay on a specific revision, the appropriate command
would be "svn up -r 5 ...".
But as common-files is already at revision 5 that command would do
nothing.
HTH
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with externals
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Finley, Stephen schrieb:
> If I do any update on the myproject directory it would get the correct
> version of the files, but if I went and did an update on the
> common-files directory it would update to the latest version of these
> files in /myprojects/common-files not version 5.
Like some other people mentioned here, this is a feature and not a bug.
I have to admit that it can cause lots of problems because the
svn:externals are not really transparent.
But I think that referring to a certain revision in an external is also
very dangerous; instead of using r5 of myproject2/common-files you
should instead first create a tag or release like
svn cp -r5 myproject2/trunk/common-files \
myproject2/releases/myrelase_123/common-files
and afterwards use the HEAD revision of
myproject2/releases/myrelase_123/common-files for your svn:external
reference.
You have to keep in mind that after restructuring a repository the
revision numbers can have changed, so external references could point
to the wrongs revisions without causing an error message. If after
restructuring a repository a path becomes invalid you would at least
get a proper error.
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with externals
Posted by Francois Beausoleil <fr...@gmail.com>.
Hi !
2007/2/5, Finley, Stephen <st...@fmr.com>:
> Myproject has property set to use external revision 5 of
> myproject2/common-files in directory common-files
>
> So you would end up with the directory
>
> /myproject/common-files
>
> If I do any update on the myproject directory it would get the correct
> version of the files, but if I went and did an update on the
> common-files directory it would update to the latest version of these
> files in /myprojects/common-files not version 5.
As Frodak said, Subversion has two working copies. If you want just
one, I suggest looking into alternatives: SVK or Piston. svnmerge
could also be used to manage subfolders if you are in the same
repository.
Hope that helps !
--
François Beausoleil
http://blog.teksol.info/
http://piston.rubyforge.org/
RE: Problems with externals
Posted by Frodak <fr...@yahoo.com>.
--- "Finley, Stephen" <st...@fmr.com> wrote:
> I do see this as an error if for some reason I am
> telling my project to
> link to a specific location in the other project
> that the directory I am
> linking it to should also retain that info. Why
> would I want my project
> to link an specific set of file but then when I go
> to that directory and
> maybe accidentally do an update I now have the
> incorrect of file for
> this project.
>
I'm guessing my work pattern is different from yours,
let say in proja has an external definition to sub1.
When I need to make updates to the contents of sub1, I
edit the files in sub1 as normal. Then at the command
prompt I type svn stat, to see if sub1 is out of date.
I'll get an output like:
$ svn stat
X sub1
Performing status on external item at 'v1'
M sub1/file1.c
Then I'll need to perform an update command to update
sub1 to the HEAD revision. That is:
$ svn up sub1
M sub1/file1.c
Updated to revision 24.
Then I can commit my changes. Note, then I'll have to
update proja to choose the correct revision of sub1
that I want. Unfortunately the problems I run with
using externals is that changes in proja are not
atomic with changes in sub1.
In this case the svn update command is working
consistently both on the proja directory and on sub1
directory. In the case of proja,its contents are
brought up to the HEAD revision (which is proja items
are at HEAD revision and sub1 is to the defined
external revision). In the case of sub1 it is brought
up to HEAD revision.
I guess I don't see this as an error because the svn
book states that when using the update command without
a specific revision it brings the working copy up to
the head revision. Besides it saves me from typing
svn up -rHEAD sub1.
As for the concern of accidentally updating the sub1
directory, and least the output of subversion will
tell you what you are updating to.
BTW, I seen some suggestions of not using externals in
these kinds of cases, but using the switch command
instead. I, personally, haven't tried this approach.
:-)
Frodak
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Problems with externals
Posted by "Finley, Stephen" <st...@fmr.com>.
I do see this as an error if for some reason I am telling my project to
link to a specific location in the other project that the directory I am
linking it to should also retain that info. Why would I want my project
to link an specific set of file but then when I go to that directory and
maybe accidentally do an update I now have the incorrect of file for
this project.
Steve
-----Original Message-----
From: Frodak [mailto:frodak17@yahoo.com]
Sent: Monday, February 05, 2007 1:28 PM
To: Finley, Stephen; users@subversion.tigris.org
Subject: Re: Problems with externals
--- "Finley, Stephen" <st...@fmr.com> wrote:
> Hi all
>
> I am not sure if I am missing something with
> externals or not.
>
> I set the properties on a directory to be an
> external to a specific
> revision. If I do an update at the top level I get
> the correct code, but
> if I do an update on the external directory I get
> the latest code for
> those files not the revision. I believe this is an
> error in subversions
> handling of externals.
>
> I hope what I am saying makes sense.
>
>
> Example.
>
> Myproject has property set to use external revision
> 5 of
> myproject2/common-files in directory common-files
>
> So you would end up with the directory
>
> /myproject/common-files
>
> If I do any update on the myproject directory it
> would get the correct
> version of the files, but if I went and did an
> update on the
> common-files directory it would update to the latest
> version of these
> files in /myprojects/common-files not version 5.
>
>
>
> Thank for any help
>
> Steve
When you do the svn up on the myproject directory (i.e
svn up .) the svn:external tag indicates to update to
version 5 of the common-files.
When you specifically perform an update on
common-files (i.e. svn up common-files) you are
telling it to update the contents of the common-files
to update to the HEAD revision.
I don't feel that this is in error. My understanding
is that common-files essentially is a separate working
copy from my-project. Which is why commands like "ci"
don't work seamlessly across both.
________________________________________________________________________
____________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with externals
Posted by Frodak <fr...@yahoo.com>.
--- "Finley, Stephen" <st...@fmr.com> wrote:
> Hi all
>
> I am not sure if I am missing something with
> externals or not.
>
> I set the properties on a directory to be an
> external to a specific
> revision. If I do an update at the top level I get
> the correct code, but
> if I do an update on the external directory I get
> the latest code for
> those files not the revision. I believe this is an
> error in subversions
> handling of externals.
>
> I hope what I am saying makes sense.
>
>
> Example.
>
> Myproject has property set to use external revision
> 5 of
> myproject2/common-files in directory common-files
>
> So you would end up with the directory
>
> /myproject/common-files
>
> If I do any update on the myproject directory it
> would get the correct
> version of the files, but if I went and did an
> update on the
> common-files directory it would update to the latest
> version of these
> files in /myprojects/common-files not version 5.
>
>
>
> Thank for any help
>
> Steve
When you do the svn up on the myproject directory (i.e
svn up .) the svn:external tag indicates to update to
version 5 of the common-files.
When you specifically perform an update on
common-files (i.e. svn up common-files) you are
telling it to update the contents of the common-files
to update to the HEAD revision.
I don't feel that this is in error. My understanding
is that common-files essentially is a separate working
copy from my-project. Which is why commands like "ci"
don't work seamlessly across both.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org