Patch to follow. The lightweight checkout is similar to Subversion or CVS checkout, which is enough as overlay users don't need a full repository. This speeds up operation a lot. Anyway, the drawback is that syncing with existing "old" repositories will not work anymore, the user needs to readd them. Maybe a check for ${overlay}/.bzr/repository/ directory can be implemented and throw an error.
Created attachment 182522 [details, diff] Improve bzr support
Some users (like myself) have overlays added in which they actually want to be able to edit and commit changes back to the repository. I'm not sure it's safe to assume that they all want a lightweight checkout - they may *want* their own branches so they can do local commits. On the other hand, that "--overwrite" option is dangerous for such an environment, so it seems that the assumption has actually already been made. What really needs to be decided is whether to support that environment or not. If so, then continue using full branches but without "--overwrite"; or go with the lightweight checkout if not.
(In reply to comment #2) > Some users (like myself) have overlays added in which they actually want to be > able to edit and commit changes back to the repository. I'm not sure it's safe > to assume that they all want a lightweight checkout - they may *want* their own > branches so they can do local commits. You should do a separate checkout if you want to change things. What is the reason? Local patching? > On the other hand, that "--overwrite" option is dangerous for such an > environment, so it seems that the assumption has actually already been made. > What really needs to be decided is whether to support that environment or not. > If so, then continue using full branches but without "--overwrite"; or go with > the lightweight checkout if not. Layman just creates an overlay not a repository to work with, so they are volatile data.
It's always just been very convenient that the layman overlays *are* checkouts, so making changes is as easy as making your edits, merging and testing, then committing/pushing. For example, I have ten boxes or so that share my private overlay (ebuilds for shared configs, apps not otherwise available, and other such things). The overlay is pulled to each machine via layman. It can sometimes happen on any one of these machines that an ebuild needs a tweek due to something specific to that machine. I need to make the changes to the overlay on that machine. Not thinking of the layman overlays as checkouts means that when I have such a problem, I now hove to first go manually check out another copy of the overlay (despite the fact that I already have one), edit make.conf to add the new checkout to PORTDIR_OVERLAY, delete the overlay with layman to ensure that Portage is seeing only my working copy, make my changes, test, commit (& push), then delete my working copy, edit make.conf to restore PORTDIR_OVERLAY and re-add the overlay with layman (yet another checkout). Yes, it's workable. But at that point, it would be more convenient to *not* use layman, and instead have a permanent checkout on each machine that is explicitly pointed at by PORTDIR_OVERLAY. That's fine, but the decision to take away that convenience by arbitrarily deciding that layman's checkouts are anything but perfectly valid working copies seems unnecessary to me. What would be nice is a config setting (either per back-end or per overlay) that can override the default checkout and update commands, or something similar. That way, using Bazaar as my example, you get lightweight checkouts by default when that's all you need, but you can have full branches when that's what you want.
For most of the Gentoo overlays Christian is right: Users only need the lightweight checkout. But in its core layman is just a repository manager. Of course its primary objective is to manage Gentoo overlays. But Mike is certainly not the only one using it for private overlays. I do so myself and have a private overlay list for that. The solution I'd like to suggest: Would it be okay to add a bzrlight.py driver? So we'd keep the original bzr.py and just add the bzrlight option. We could switch the layman-global list from bzr to bzrlight (there are currently only two such overlays). People could still override this setting by using a personal overlay list. Guess I could do the same for the git driver. Please notify me if one of you two disagrees. I plan on releasing layman-1.2.4 this week.
Well, that addresses part of the problem, and certainly would work for me and my totally private overlay. However, it seems like it's an extra hurdle for someone who contributing to one of the public overlays. If I'm a dev and I get accepted as a committer for the foo overlay (or even just a user who wants to make a one-time contribution, in which case I still need the ability to commit locally), all I should have to do is "layman -a foo" and start contributing. If foo's official listing uses this bzrlight driver, though, that won't work. I have to do all of that extra stuff I described before. I'll grant that these steps are fairly trivial for a dev, but I'm also against making people do work, even (or maybe especially?) trivial work that is simply unnecessary. I'd much rather see something like "layman -a --full foo", or a one-place config setting for the repo, or something like that. Maybe even a "-o" argument that lets you send any option you want to the vcs command (probably with some parsing of "no"-options, so you could do "layman -a -o '--no-lightweight'").
Okay. Seems reasonable. The "--full" option or something similar probably makes most sense. I'll look into that for the next release. Thanks for the feedback!
(In reply to comment #7) > Okay. Seems reasonable. The "--full" option or something similar probably makes > most sense. I'll look into that for the next release. Thanks for the feedback! Great to see you back in action. All solutions are fine with me.
After discussing it with sping, we decided to leave it as is. Layman will fetch the whole repository for Bazaar overlays.
Might I inquire as to the reasoning? I thought the faster lightweight checkouts would be a nice option in general for VCS's that have an analogous feature. Mike
bzr 2.0 is a lot faster than previous version. There was opposition to the lightweight-only plans and including an --full option is too much work such a small user-base. The overlays using Bazaar are pulled/cloned really fast.
