disclaimer:<br>I answered the questions from my experience with scmproj, <br>I have not looked at how it is used with this bzr.exe.<br><br>2008/12/31 Mark Hammond <span dir="ltr"><<a href="mailto:skippy.hammond@gmail.com">skippy.hammond@gmail.com</a>></span><br> <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On 23/12/2008 2:35 AM, Alexander Belchenko wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi all, and especially Mark Hammond.<br> <br> This is second mail about scmproj announcing.<br> <br> I've prepared testing bzr.exe.project based on<br> bzr.dev/tools/win32/build_release.py script.<br> </blockquote> <br></div> Hi Alex,<br>  This example project works as you describe.  It looks like a very useful tool!  Some comments:<br> <br> * 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?</blockquote> <div><br>for bzr branches it will work, so long as it is *inside* the project.<br>I dont have experience with  svn:externals but assume it works the same.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * 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?</blockquote> <div><br>NO, its about excluding components (which each can have their own branches) <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> )<br> <br> * "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?</blockquote> <div><br>in my experience the project layout is quite stable, so this has not<br>caused problems for me. I like my scripts to be a separate branch<br>from my project layout. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> * On a similar note:<div class="Ih2E3d"><br> <br> > To cut down the path you can use following options of the command:<br> ><br> > bzr pfetch bzr --source-branch=/path/to/bzr.dev/local/mirror<br> <br></div> 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 :)</blockquote> <div><br>there is a file intended for local configs:<br>.scmproj/local.cfg<br>but it doesn't have this functionality ATM<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> * 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...)<br> <br> * 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 :)</blockquote> <div><br>Is it all the comments inside that makes it a bit unreadable for you?<br>Do you have any suggestions as to how we can improve this?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div>I also think Alexander is doing a great job with scmproj. <br> </div></div><br>-- <br><| regards<br>U| Marius<br>H| <>< <br>