Justin Georgeson [19/Jun/13 02:53 PM] Has this been considered at all? Managing all the externals URLs is a real productivity killer for me. It could be implemented as follows 1. First build of a configuration, take snapshot of each configured Repsitories, build executes 2. During build Repositories are checked out. After each checkout completes, run 'svn status --xml' and parse the file for entries <entry    path="path/to/external/wc"> <wc-status    props="none"    item="external"> </wc-status> </entry> take snapshot of each such entry. 3. Scheduled build triggers, perform normal process of 'svn info' on configured Repositories to compare HEAD revision to snapshot from previous build. If any externals properties were modified, this creates a new revision in the configured repository, so the build condition is met. Take new snapshots of the configured Repositories, execute build. 4. The build does 'svn update' of the configured repositories and runs 'svn status --xml' on each working copy to refresh the list of externals. Take snapshots of externals. Can now list commits to externals which had snapshots from previous build. Can also delete svn:externals working copies which had a snapshot in previous build but are no longer present in the XML status report (the svn update does not delete unversioned files/folders).

Robin Shen [20/Jun/13 02:04 AM] Yes we investigated this but it turns out to be quite involved to implement this. Since this ticket gets very few votes from different sites, it is not in the high priority list. As to the approach you mentioned, it will not work in QB as one assumption of repository in QB is to be able to take snapshot and calculate changes without having to checkout the repository first, as otherwise we will have a lot of troubles when dealing with workspace usage. Also some externals might snap to a version at this time, then switch to a different version later one, in this case, it is really difficult to detect such changes and calculate changes between those versions.

Justin Georgeson [20/Jun/13 03:51 PM] The repo with the svn:externals properties would be defined normally in Repositories, and the snapshot would be pre-build/pre-checkout as normal. Any changes to the svn:externals properties will be reflected in commits that the snapshot recorded. So a change to the svn:externals property would itself trigger a build. QuickBuild's workflow could be svn checkout --ignore-externals svn status --xml <parse XML file and snapshot externals> <delete external working copies which are not listed in the svn:externals properties> svn update If the svn:externals property specifies a revision number, then the snapshot should reflect that the revision is unchanged and therefore no change sets to add to the report. The update at the end does the checkout of the externals. So that preserves the assumption of doing a snapshot before a checkout. I also need to point out that, the SVN command-line client already reports the commits per external working copy, so this functionality is something that SVN handles out-of-the-box but QuickBuild's implementation takes away.

Robin Shen [21/Jun/13 12:46 AM] Your workflow requires QB to checkout working copy (then run svn status --xml to get external status) first before determining external revision and calculate external changes, and this violates QB's current assumption of being able to taking shapshot and calculating changes without relying on a working copy, and has big impacts on current repository workflow. So we need more votes from different sites to make this big change.