scmproj: testing project: bzr.exe.project as bzr.exe building workspace
amanic at gmail.com
Wed Dec 31 08:09:04 GMT 2008
I answered the questions from my experience with scmproj,
I have not looked at how it is used with this bzr.exe.
2008/12/31 Mark Hammond <skippy.hammond at gmail.com>
> 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?
for bzr branches it will work, so long as it is *inside* the project.
I dont have experience with svn:externals but assume it works the same.
> * 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
NO, its about excluding components (which each can have their own branches)
> * "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?
in my experience the project layout is quite stable, so this has not
caused problems for me. I like my scripts to be a separate branch
from my project layout.
> * 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 :)
there is a file intended for local configs:
but it doesn't have this functionality ATM
> * 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 :)
Is it all the comments inside that makes it a bit unreadable for you?
Do you have any suggestions as to how we can improve this?
> 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.
I also think Alexander is doing a great job with scmproj.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar