> On 7/28/05, Simon Large <email@example.com> wrote:
>>>If you include the externals inside your project, you just have to
>>>check out *one* URL and you're done - isn't that the whole point of
>>Mostly, yes. But in this case all the externals point to tags, not live
>>development branches, so they only need updating when the svn:externals
>>value changes to a different tag. Don't you get bored when you run
>>update on trunk, checking for updates to subversion which you know
> So what you're really complaining about is TSVN having the external
> sources like apr/Subversion/neon included, not the task #141.
I am not complaining. I think having the external sources included is
good, but I would prefer to see them separated from trunk. But I know
that also has its own problems.
Task #141 comes, I think, from you and not the mailing list. So I am
guessing that TSVN's externals are slowing you down ;-)
One other problem in the method you describe in task #141 is that I am
not sure that it is a good general solution. Is it appropriate for
project properties to define whether externals are scanned. It would
work in the TSVN case because a) the externals are tags and b) none of
has commit access in SVN. But for other organisations, maybe one person
has commit access and they _do_ want those externals scanned on commit.
Everyone else has read-only access and the _don't_ want the externals
Another (imperfect) solution would be to have a client option to omit
scanning of externals which include /tags/ in the URL. Maybe you could
also have an option to exclude those from simple updates too. Of course
Update-to-rev would include them, unless Omit-externals is checked.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jul 28 12:18:44 2005