No subject

Fri Dec 18 02:33:18 GMT 2009

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?

--00504502b021322df8047cb02943
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi guys, I&#39;ve gotten a lot of replies to my initial email and can&#3=
9;t reply to all of it right now due to the volume but will try to get to i=
t over the weekend. From what I&#39;ve read so far, and after looking at st=
acked 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 geog=
raphically distributed lockstep development. That aside, I still think that=
 Bazaar won&#39;t quite work for us yet.

Our repository is only 10GB right now because we&#39;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 100G=
B. That&#39;s actually mostly text by the way, though most of it is not gen=
erated 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 wan=
t them version controlled. We&#39;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&#39;s value in making these branch opera=
tions faster and smaller.

I&#39;m supposing now that we have integration branches in one shared r=
epository 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 reposito=
ry 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&#=
39;t handle now) and that&#39;s not a problem - a stacked treeless branch t=
akes 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 decompre=
ss 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 cre=
ate a partial tree branch. Something like:

<br>bzr branch --stacked --expand software --expand tests/test1 ../trunk<br=
><br>After creating the tree you might want to modify it as well so there s=
hould be a command to expand missing parts of the tree:<br><br>bzr branch -=
-stacked --no-tree ../trunk<br>

bzr expand software bzr expand tests/dir1/dir2/test1 The cloned r=
epository is then still aware of all of the files but you only need to cons=
ume the space and time needed for a portion of it. The &quot;expand&quot; c=
ommand should have a -norecurse option by the way. This is the only impedim=
ent that I can see now to using Bazaar on really large repositories and I o=
ptimistically imagine it would be simple to implement (maybe I&#39;ll take =
a look this weekend). Unfortunately, I think my group may have passed the p=
oint 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 bran=
ch bind should be sticky. If the mirror is read only, then the new branch s=
hould 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 thou=
gh. Maybe the mirror could have a sticky option on the bind so that all bra=
nches 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 bindin=
g rather than looking at the branch.conf file by the way. Something like: b=
zr branch -show. Maybe it&#39;s elsewhere and I missed it. What do y=
ou all think about these proposals?

--00504502b021322df8047cb02943--