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

[Marius Kruger]

disclaimer:
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
> branch?


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:
.scmproj/local.cfg
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.

-- 
<| regards
U| Marius
H| <><
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081231/d4984c1d/attachment-0001.htm