How to have one of the components at the top level?

Geoff Bache пишет:
> New question #60456 on ScmProj plugin:
> https://answers.launchpad.net/bzr-scmproj/+question/60456
>
> As described in my original question, I'd like to have a project consisting of a top level "generic" component and a "site" subdirectory,
> which are two separate bzr repositories. Is this possible with scmproj?

Yes, it's possible.

> It didn't seem to like me not specifying "RELPATH". So I tried RELPATH = .

This is right: `RELPATH = .` for the component in the root of the project checkout
is mandatory.

> but then when I came to checkout the project (after doing bzr pget)
> the command "bzr pco" failed, saying
>
> # Component: generic
> # Creating working copy in "."...
> bzr: ERROR: Not a branch: "/home/geoff/bzrtest/scmprojcheckout/".
>
> The "site" component, which has a subdirectory seems to work if I do "bzr pco site"

I'm not sure what is your problem, may be it's the bug.

We have seriously reworked the scmproj internals and have changed project config format
and meta-data layout. It will be better if you upgrade and continue with new version.

Please, do following:

1) Update the scmproj plugin to latest version (0.4.5.dev.1 ATM)
2) Read http://bialix.com/scmproj/docs/early-adopters.html and update your project
   accordingly
3) To create checkout try to execute following commands:

bzr pget PROJECT_URL /path/to/some/empty/dir
cd /path/to/some/empty/dir
bzr pco --fetch

If it will failed the same way as before, can you please file a bug and provide the info
from your ~/.bzr.log file related to this issue (typically it should be at the end of file).

If your project is open-source I'd like to see your project.cfg, may be I can suggest
some useful tips to you.

Thanks.

Well, it didn't fail the same way as before, but now when I do "bzr pget" I get a new project.cfg file which is the same as the initial one (i.e. it isn't a copy of the one at the place where I did pget from). Then bzr pco does nothing, which isn't surprising given the above I suppose.

My project.cfg file:

## describe each component in subsequent sections, e.g.:
[component generic]
RELPATH = .
BRANCH_URL = /home/geoff/bzrtest/scmproj

## describe each component in subsequent sections, e.g.:
[component site]
RELPATH = dir2
BRANCH_URL = /home/geoff/bzrtest/scmproj/dir2

I'm just playing around at the moment, but I'm already concluding that this project is probably a bit too "alpha" for me to want to use it for real at the moment, and it may well be overkill anyway for what I'm trying to do. I'm considering just writing a script "bzrs" that will run bzr in the current place, then find its way to the "other" repository and run it there too. That should be pretty easy to do and will solve most of the problem, as I don't foresee needing lots more repositories any time soon.

One of my concerns with scmproj is that the interface is rather different to bzr itself. I think a noble aim would be to have this as similar as possible. For example, I would expect to checkout a project just by doing bzr pco SOURCE [LOCATION] as I would with "bzr co". I would also expect e.g. bzr pinit to default to doing so in the current working directory if no argument is supplied.

Ultimately, my aim is to hide as much as possible the fact that there are two repositories at all, as this is not interesting to the average person working on the code.

Geoff Bache пишет:
> Geoff Bache is still having a problem:
> Well, it didn't fail the same way as before, but now when I do "bzr
> pget" I get a new project.cfg file which is the same as the initial one
> (i.e. it isn't a copy of the one at the place where I did pget from).
> Then bzr pco does nothing, which isn't surprising given the above I
> suppose.

I'm sure this is because lacks of the documentation. The scmproj is pretty new,
as you see.

> My project.cfg file:
>
> ## describe each component in subsequent sections, e.g.:
> [component generic]
> RELPATH = .
> BRANCH_URL = /home/geoff/bzrtest/scmproj
>
> ## describe each component in subsequent sections, e.g.:
> [component site]
> RELPATH = dir2
> BRANCH_URL = /home/geoff/bzrtest/scmproj/dir2

It seems this is not clear in the documentation, but the .scmproj control dir
has actually separate bzr branch inside. And you need to commit your new
config before you do successful pget.

> I'm just playing around at the moment, but I'm already concluding that
> this project is probably a bit too "alpha" for me to want to use it for
> real at the moment, and it may well be overkill anyway for what I'm
> trying to do.

This is possible. Yes, it's alpha. Yes it's new. Yes, I'm still polishing UI and
implementation.

And anyway -- THANK YOU VERY MUCH for trying it.
Your feedback is invaluable for me.
And I'm sorry if you feel you have wasted your time with scmproj.

> I'm considering just writing a script "bzrs" that will run
> bzr in the current place, then find its way to the "other" repository
> and run it there too. That should be pretty easy to do and will solve
> most of the problem, as I don't foresee needing lots more repositories
> any time soon.

This will work too, yes.

> One of my concerns with scmproj is that the interface is rather
> different to bzr itself. I think a noble aim would be to have this as
> similar as possible. For example, I would expect to checkout a project
> just by doing bzr pco SOURCE [LOCATION] as I would with "bzr co". I
> would also expect e.g. bzr pinit to default to doing so in the current
> working directory if no argument is supplied.

Well, this is arguable. I've started this project with vcs-agnostic in mind.
It was not intended to be bzr-only solution. Of course everything may change
over time.

> Ultimately, my aim is to hide as much as possible the fact that there
> are two repositories at all, as this is not interesting to the average
> person working on the code.

You really need nested trees then. I hope they will be finally implemented
in near 2-3 months.

Thank you again.

If you will decide to get the scmproj second chance I'll be happy to answer
any new question.

OK, I didn't realise there was a bzr branch inside the .scmproj directory. Once I committed there then it worked.

This wasn't at all a waste of my time: I'm sure it will be very useful in time. Though it's probably a bit overkill for my case even when it matures: it doesn't quite do what I want and it introduces a certain amount of extra complexity, especially with having to learn quite a different interface. As you say what I really want is nested trees supported natively, if there is any chance that will ever actually happen :)

I would have thought you could still be vcs-agnostic and have a bzr-friendly interface for the commands. It seems bzr is the "favourite" vcs in any case, as you're using it and launchpad yourself...

Geoff Bache пишет:
> Geoff Bache confirmed that the question is solved:
> OK, I didn't realise there was a bzr branch inside the .scmproj
> directory. Once I committed there then it worked.
>
> This wasn't at all a waste of my time: I'm sure it will be very useful
> in time. Though it's probably a bit overkill for my case even when it
> matures: it doesn't quite do what I want and it introduces a certain
> amount of extra complexity, especially with having to learn quite a
> different interface. As you say what I really want is nested trees
> supported natively, if there is any chance that will ever actually
> happen :)

Scmproj plugin is also tries to introduce some additional features
beyond nested trees emulation, so I agree it will be useful anyway.

> I would have thought you could still be vcs-agnostic and have a bzr-
> friendly interface for the commands. It seems bzr is the "favourite" vcs
> in any case, as you're using it and launchpad yourself...

Yes, I'm addicted to bzr. OK, anyway I'm planning to rework CLI,
so I'll think about make the UI closer to bzr.

Thank you again.

BTW, I'll make announces about major changes in scmproj, you can use RSS
to track the news ;-)

http://feeds.launchpad.net/bzr-scmproj/announcements.atom

Based on this discussion I've filed the bug about changed-and-not-committed project.cfg during pget local operation: https://bugs.launchpad.net/bzr-scmproj/+bug/327955