Hi Neels,
Would this help 'svn commit' descend into external directories and check them
in?
<<<
Perhaps most disappointingly, the 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 truly operates only on nondisjoint 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.
<<<
This is a long-standing described limitation which becomes more and more of an
issue in our set-up...
Regards,
Alexey.
On Thursday, October 06, 2011 01:28:58 pm Neels J Hofmeyr wrote:
> Hi all,
>
> I have committed code to trunk that populates the EXTERNALS table during
> upgrade from 1.6. With a nudge from Philip, I noticed that the EXTERNALS
> table is still a neither-here-nor-there implementation. Now I'm unsure.
>
> This table is / would be very useful if one tries to find all externals
> defined or checked out in a given subtree, without having to first find and
> then parse all externals skels.
>
> But in fact it is little more than a cache for svn:externals props. It
> duplicates information in a way. But it adds the knowledge of exactly which
> repository and relpath an external is from (stores URLs in repos-root and
> repos-relpath, readily parsed from the various formats found in
> svn:externals definitions).
>
> So it is useful for speeding up things, but it also has a danger: heavens
> forbid if the EXTERNALS table is ever out of sync with the svn:externals
> props. So, we may often be forced to parse the props anyway (cleanup?).
>
> What do you guys think about the EXTERNALS table? Yay or nay? What thought
> has gone into this so far?
>
>
> Your answer is interesting to me right now because it will change the fixes
> for file-externals-under-unversioned (WIP) and it will either shorten or
> obsolete this nomination:
>
> [[[
> * r1173574, r1174342, r1174693, r1174699, r1178910
> Fix issue #4016: 'externals after upgrade from 1.6 have wrong URL
> information in EXTERNALS rows'
> Also: previously, the first failing external upgrade aborted all other
> external upgrades, now just prints the error and carries on.
> Justification:
> Users will start upgrading their WCs soon, and it would be nice to
> have proper information in wc.db. I know of no real problems when
> EXTERNALS rows are wrong and/or missing info, but we might see them
> soon enough, or hit problems if same users upgrade same WCs to 1.8,
> much later.
> Argument against: "If EXTERNALS is just some sort of cache perhaps
> upgrade should just leave the columns null?"
> Argument for: "Currently 1.7 populates those columns. So upgrade
> should, too. We don't know which way we'll go -- drop EXTERNALS
> columns or heavily rely on them. So rather make an upgraded 1.6 WC
> look exactly the same as a fresh 1.7 WC would, saving us special
> cases in subsequent upgrade code. Meaning: power users with age-old
> WCs won't get dropped during upgrade to 1.8, whichever way we
> choose."
> Notes:
> r1173574 is just a cosmetic change that avoids conflicts in r1174693.
> r1174699 removes obsoleted stuff, but doesn't change the outcome.
> r1178910 fixes upgrade_tests.py 2 on windows.
> The entire patch seems quite large, but a large portion of it is just
> moving a function from static to private API.
> Conflicts:
> --accept=tc
> (r1174693, indent mismatch in handle_external_item_change() caused by
> cosmetic fix from r1169770)
> Votes:
> +1: neels
> ]]]
>
> Thanks,
> ~Neels
>
> (What is it with externals, that they always seem to bring out ambivalent
> half-hearted implementations that have everyone stumped?)
Received on 2011-10-06 23:40:02 CEST