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

[Alexander Belchenko]

Mark Hammond пишет:
> On 23/12/2008 2:35 AM, Alexander Belchenko wrote:
>> 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.

Perhaps I've compared scmproj to svn:externals in very broad sense.
Actually my tool is much closer to CVS modules. I have no experience
with svn:externals at all.

>  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?

There is no limitations on layout of components. You're just need to provide
RELPATH for every component as you want to lay them.
So you can specify for bzrtools RELPATH as bzr/bzrlib/plugins/bzrtools.
In this case bzrtools will be placed in corresponding directory.
Even if you don't create checkout for bzr it will not block checkout
for bzrtools. It's very similar to the way how python setup.py install
works.

> * The description of "views" sounds very interesting, but I fear
> confusion with the "filtered views" work being done by Ian.

Yep. :-(
I should admit that I was not aware of Ian work when I've chosen "view"
word as term for scmproj. I think it will be better to avoid using it
in scmproj. After chat with Marius Kruger I'm planning to change it
to "subset".

>  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 my "views" (now "subsets") is about managing set of components.
Scmproj itself working in the term of components.

> * "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?

project.cfg supposed to be versioned in snapshot branch (not implemented yet).
local.cfg is for local settings, they never should be versioned.

Mark, I've learned the lesson of last April. I should say that both variants
has some pros and cons. I want to have ability to put working files into
root of the project. Neither hg nor git don't allow this. Placing project.cfg
into project root will prevent my idea.

> * 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 :)

Yes, I'd like to provide this feature. Define mirror URLs in local.cfg
or global ~/.bazaar/scmproj.conf.

> * 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...)

pfetch will be useful to work with several alts.

You can use pco --fetch as well.

> * 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 :)

Yep. There is too much planned supported features, so it can be complex.