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

[Alexander Belchenko]

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

Yes, there is a lot of things we can make optional.
We discussed with Marius how we want to change project.cfg format,
and we inclined towards git format, i.e. don't declare components first
as list but only as named sections, i.e.:

[PROJECT]
name = super-project!
...
[component "foo"]
...
  [branch "trunk"]
  ...

Make BRANCHES optional is possible but a bit tricky. See bug #313654.

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

I think you're right, I'm just more focused to make scmproj bigger and better tool than
just supporting bunch of branches. I want to have alts, subsets and local
short-lived feature branches. Yes, your proposal makes very high sense for me.
I'm thinking about some sort of simple tutorial for simple use case.
It's always tradeoff: write more code or more docs. Today I need a little bit
more code. Once I'll finish with snapshots I'll try to write tutorial sketch.

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

Mmm, maybe in the future, but not today, sorry.
I'm already have project-commit command (with pci alias).
I have no problems to implement project-status (pst), project-diff (pdi) etc.

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

Yes, I agreed.

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

Heh. Bazaar is not git nor hg. It does not support multiple branches inside
one dir. To emulate git behavior I need to hide real branches inside .scmproj.
So, if you don't need neither alts feature nor local short-lived feature branches,
nor subsets, you certainly want to avoid lightweight checkouts and use real branches
in the project working space instead.

I want to note that placing branches inside .scmproj is not mandatory.

You can do

bzr pget URL
bzr pco

i.e. create checkout without fetch, and in this case you'll end up with heavyweight checkouts
in your project workspace without local copies inside .scmproj.

I can support your configuration via some command-line option for project-checkout command.
It's easy. Actually my first proof-of-concept code work exactly in this way.

Just one more time: placing local copies of branches inside .scmproj is recommended way,
but it's not mandatory.

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

Yes, it's very cool to have such detailed feedback, thank you very much.
I've filed several bug reports based on your suggestions:
bugs #313652, #313653, #313654, #313655.

Thank you!