scmproj: testing project: bzr.exe.project as bzr.exe building workspace
skippy.hammond at gmail.com
Wed Dec 31 00:25:31 GMT 2008
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.
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
More information about the bazaar