Feedback from evaluation in a corporate environment

[Uri Moszkowicz]

Resending because it looks like only the first line of my email made it to
the list for some reason. Strangely, it only made it to one of the archives
as well.

https://lists.ubuntu.com/archives/bazaar/2010q1/065886.html
http://news.gmane.org/gmane.comp.version-control.bazaar-ng.general


On Fri, Jan 8, 2010 at 7:12 PM, Uri Moszkowicz <uri at 4refs.com> wrote:

> Hi guys,
> I've gotten a lot of replies to my initial email and can't reply to all of
> it right now due to the volume but will try to get to it over the weekend.
> From what I've read so far, and after looking at stacked branches and shared
> repositories a little closer, I think I get what you all are getting at with
> the branches only being slow the first time and the insignificance of the
> space. The efficient use case for Bazaar is not obvious and perhaps an
> example could be given in the documentation for geographically distributed
> lockstep development. That aside, I still think that Bazaar won't quite work
> for us yet.
>
> Our repository is only 10GB right now because we've left a bunch of files
> out of the repository already. While we could continue this practice, it is
> really worth noting that our repository would really be around 100GB. That's
> actually mostly text by the way, though most of it is not generated by us
> and not publicly accessible from another repository so we have to keep a
> copy of it ourselves. We do modify the files which is why we want them
> version controlled. We're just living without it for the moment. Even if the
> space and time were both tolerance to copy the trees, they are certainly not
> negligible so there's value in making these branch operations faster and
> smaller.
>
> I'm supposing now that we have integration branches in one shared
> repository at one site and mirrors of them at other ties. Each user creates
> their own repository with stacked branches from the site mirror. I get the
> impression that you all want Bazaar to have a complete view of the
> repository at all times (for efficiency reason and because there may be
> operations that leave the bounds of a partial checkout that CVS/SVN
> conveniently don't handle now) and that's not a problem - a stacked treeless
> branch takes no time to create by my measurement. The problem is really that
> there is no middle ground between tree and treeless - you either have to
> decompress it all or none of it and with 10GB - 100GB those are still long
> and disk space eating operations. What Bazaar needs, I think, is the ability
> to create a partial tree branch. Something like:
>
> bzr branch --stacked --expand software --expand tests/test1 ../trunk
>
> After creating the tree you might want to modify it as well so there should
> be a command to expand missing parts of the tree:
>
> bzr branch --stacked --no-tree ../trunk
> bzr expand software
> bzr expand tests/dir1/dir2/test1
>
> The cloned repository is then still aware of all of the files but you only
> need to consume the space and time needed for a portion of it. The "expand"
> command should have a -norecurse option by the way. This is the only
> impediment that I can see now to using Bazaar on really large repositories
> and I optimistically imagine it would be simple to implement (maybe I'll
> take a look this weekend). Unfortunately, I think my group may have passed
> the point of going back to the decision making process for which tool to use
> but who knows maybe next time.
>
> Thinking of the mirroring some more, in the master/slave model the branch
> bind should be sticky. If the mirror is read only, then the new branch
> should copy the bind of the original. If not, then they should daisy chain.
> There should be some way to avoid having to rebind every single branch
> though. Maybe the mirror could have a sticky option on the bind so that all
> branches created from it keep its binding rather than being bound to it.
>
> It would be nice if there were some way to discover the existing binding
> rather than looking at the branch.conf file by the way. Something like: bzr
> branch -show. Maybe it's elsewhere and I missed it.
>
> What do you all think about these proposals?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100108/a2379ec5/attachment-0001.htm