scmproj: testing project: bzr.exe.project as bzr.exe building workspace

[Mark Hammond]

On 23/12/2008 2:35 AM, Alexander Belchenko wrote:
> Hi all, and especially Mark Hammond.
>
> This is second mail about scmproj announcing.
>
> I've prepared testing bzr.exe.project based on
> bzr.dev/tools/win32/build_release.py script.

Hi Alex,
   This example project works as you describe.  It looks like a very 
useful tool!  Some comments:

* You use svn:externals as an example - however, I often find 
svn:externals used somewhere *inside* a project rather than at the root. 
  For example, my main project may have a 'lib' directory, and this 
directory may use svn:externals to pull common shared code directly to 
where it can be imported.  For example, think of pulling plugins 
directly into bzr's plugins directory rather than update-then-copy.  Is 
there scope in scmproj for this kind of layout?

* The description of "views" sounds very interesting, but I fear 
confusion with the "filtered views" work being done by Ian.  Indeed, the 
concept of 'views' as you describe them seems largely independent of 
what scmproj is trying to do (ie, IIUC, scmproj is primarily about 
combining unrelated branches, while your views are all about excluding 
content from a single branch?)

* "Composition of the scmproj control directory" - it seems a little 
strange to me that the .cfg files are stored in the .scmproj directory. 
  At first glance, I would have expected .scmproj to only hold 'temp' or 
'working', unversioned files and that the .cfg files would just be 
"normal" versioned source files in the root of the tree.  It seems the 
build scripts in this root and the layout defined in the .cfg file will 
always be intimately related?

* On a similar note:

 > To cut down the path you can use following options of the command:
 >
 > bzr pfetch bzr --source-branch=/path/to/bzr.dev/local/mirror

It seems a nice feature might be an unversioned 'local' config file that 
allows people to map branches to their hard-disk.  It might even make 
sense for this to be stored in the global user-prefs area, so that 
*every* scmproj project I did on this machine knew that 
'o:\src\bazaar\bzr\bzr.dev' was a clone of the trunk.  Obviously people 
making 'official' builds may choose to avoid this to ensure they always 
have exactly what they think, but given I've managed to write most of 
this email before the project-fetch completed, even *after* pfetching 
bzr, qbzr and tbzr, makes me think it might be worthwhile :)

* Is there any reason project-checkout couldn't automatically perform 
the initial project-fetch, allowing the fetch command to die?  At first 
glance it seemed strange for the 2 commands to be necessary (I just 
fetched the project, why do I now need to check it out?  I guessed the 
'fetch' was creating the repos, but it still seemed strange...)

* At first glance, the .cfg files aren't particularly readable, so its 
not immediately obvious what everything means.  I understand it has 
complex requirements and that it will likely make more sense with 
experience, but it's still an impression I thought worth sharing :)

Nice work!  John is currently driving the bzr binary build process, so 
hopefully he will have some comments on how appropriate this is for the 
official build.

Cheers,

Mark