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

[Ian Clatworthy]

Alexander Belchenko wrote:
> Mark Hammond пишет:

>> * 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.
>>From other side there is only 3 mandatory options for every component:
> 
> RELPATH
> BRANCH_URL
> BRANCHES
> 
> Do yo think they're not obvious? At least first two?

Alex,

I'm still working my way through the various emails & documents so
apologies if I'm missing things in my feedback below.

1. I think you should look to make everything in the config file you can
   optional. Could BRANCHES be optional so only RELPATH & BRANCH_URL are
   needed? Could the [VIEWS/SUBSETS] section be optional?

2. User doc wise, I'd start with a brief description of the mental model,
   particularly the essential bit: project = list of components. I'd then
   make the 1st example as *simple* as it possibly can be - see 1. I'd also
   treat subsets, ALTs and the other clever stuff as "Advanced features".
   I know they're essential to how your team is using the plugin but my
   expectation is that 95% of users (only) care about composing projects
   from multiple branches, occasionally working with a bunch of branches as
   a batch and nothing else. (I'm happy to help with the user doc along
   these lines if you'd like.)

3. UI-wise, I'd replace project-command with just "project" and consider
   making {RELPATH} implicit if the argument has no {} markers. The idea
   is that as many commands as possible ought to look something like ...

     bzr project st
     bzr project diff
     bzr project pull
     bzr project commit -m "Fix bug #1"

4. I'd like to see a 'build-project' command that creates a .scmproj dir
   by searching sub-directories for bazaar branches. That way, users
   could reconfigure their currently manual setup of a "project" into
   your model.

5. I must say I'm not sold on *always* storing the branches
   under .scmproj and only having lightweight checkouts in the "tree",
   but I think many users will care less about the internal layout if
   a command like build-project exists. If it's possible to have an
   .scmproj dir one day that just has a project.cfg in it, then that
   setup could be an option to build-project, say.

I'll keep getting my head around how everything hangs together. In the
meantime, I hope the above is helpful feedback.

Ian C.