On Jan 25, 2008, at 10:18, Robert Dailey wrote:
> On Jan 25, 2008 9:21 AM, KM wrote:
>
>> Ryan Schmidt wrote:
>>
>>> On Jan 24, 2008, at 11:31, Robert Dailey wrote:
>>>
>>> > First of all I would like to note that I use TortoiseSVN to
>>> control
>>> > Subversion, so if possible please reference solutions in
>>> regards to
>>> > the GUI interface and avoid command line syntax. I'm not familiar
>>> > with the command line at all. Thank you.
>>>
>>> Since I don't use Windows or TortoiseSVN I can't accommodate you. :)
>>>
>>> > I'm currently using the latest nightly build of TortoiseSVN, which
>>> > utilizes SVN 1.5.0.
>>> >
>>> > Currently I have a working copy that, at some nested level down
>>> the
>>> > directory tree, has an external link to a different location in
>>> the
>>> > same repository as the working copy links to. When I have
>>> > modifications in both the parts of my working copy that are not
>>> > externally linked AND also in the parts that are externally
>>> linked,
>>> > any attempt to commit yields the following output in the commit
>>> > dialog:
>>> >
>>> > Command: Commit
>>> > Error: Are all the targets part of the same working copy?
>>> > Error: Unable to lock 'C:\IT\personal\rocket_test\engine\boblib
>>> \input'
>>> > Error: Please execute the "Cleanup" command.
>>> > Finished!:
>>> >
>>> > I remember in SVN 1.4.5 this never used to happen. I was always
>>> > able to commit external link files and working copy files
>>> > simultaneously through one commit. Am I doing something wrong? Any
>>> > help is greatly appreciated. Thanks in advance!
>>>
>>> I'm surprised this used to work. I don't think it was ever supposed
>>> to work that way. I thought you were supposed to have to commit
>>> changes in external directories separately from everything else.
>>> See:
>>>
>>> http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html
>>>
>>> "The support that exists for externals definitions in Subversion is
>>> less than ideal, though. ... [T]he working copies created via the
>>> externals definition support are still disconnected from the primary
>>> working copy (on whose versioned directories the svn:externals
>>> property was actually set). And Subversion still only truly operates
>>> on non-disjoint working copies. So, for example, if you want to
>>> commit changes that you've made in one or more of those external
>>> working copies, you must run svn commit explicitly on those working
>>> copies -- committing on the primary working copy will not recurse
>>> into any external ones."
>>>
>>> Maybe Subversion 1.5 is enforcing this more strictly.
>>>
>>> Or, another theory: Maybe TortoiseSVN includes a workaround for this
>>> situation, which broke in Subversion 1.5.
>>>
>>> You should report this problem on a TortoiseSVN mailing list, and
>>> see
>>> if they had a workaround for the problem which might need to be
>>> updated to work with 1.5.
>>
>> Really just an FYI - but i am using Tortoise 1.4.3/Subversion
>> 1.4.3 on host -
>> I do have to separately commit the changes from the external
>> directory, and the local one. If i try to do what Robert is
>> describing - I get the same error he gets.
>>
>> so it didn't work in 1.4.3 either. As Ryan said, I am surprised
>> it worked in 1.4.5. I'd go to the tortoise users list.
>
> I don't really understand the reason for forcing the user to commit
> each external individually. I personally find it annoying, because
> I like to use external links in my repository for 2 reasons:
>
> 1) To save space on the server side for projects that reuse the
> same libraries.
> 2) Each project will globally get updates to libraries they all
> externally link to, which means I don't have to make the same
> changes to (for example) 5 projects.
>
> Couldn't you make one commit do exactly what 2 commits does? First,
> commit the external links... then, commit the working copy. It
> would save me a lot of trouble. I would like to just understand the
> reason for this, if anyone would mind elaborating. Thank you.
The wording in the book makes it sound like this is not that it's
necessarily the way they want it to be, but just the way it is at the
moment.
That said, externals are supposed to be like libraries. The reason
you're using externals is probably that you want to use this bit of
code or whatever in more than one place. So, changes to the external
library should be made separately from the code that's using that
library. If you're adding a function to the library, commit that
first, then later change your project(s) to use that new function and
commit that. If you're removing a function, first remove the use of
the function from all your projects and commit them, then later
remove the function from the library and commit that.
The common advice is also that your externals should be referencing
specific tags of your external libraries, and not the HEAD of the
trunk of those libraries. This way even if you make incompatible
changes to a library (like removing a function that was used, or
changing the parameters of a function that was used) all your
existing projects continue to work, because they still reference the
old version of the library. Only when you're ready to update the
usage of the library in each project do you go in and change the tag
of the external in that project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-25 20:10:37 CET