Shallow branches question
John Arbash Meinel
john at arbash-meinel.com
Wed Mar 12 16:14:10 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicholas Allen wrote:
|
| | One of the reasons to not do it automatically is because of chaining.
| | Specifically, if I have a shallow branch of you, and then Martin has
| one from
| | me, and Robert from him, it is easy for one of them to "disappear"
| temporarily
| | or even permanently.
| |
| | I could see this even happening accidentally for a single user who
| spreads
| | things between their desktop, laptop, and server.
| But when you branch from another branch that does not have all the
| revisions yet Bazaar could remember the location where that branch needs
| to get remaining revisions from (and if that is chained then
| recursively). It then has multiple locations it can try to retrieve the
| missing revisions that are not cached locally. So if Martin's branch
| went offline then Bazaar could load the revisions from your branch, and
| if your branch is offline then from my branch etc.
Sure. The problem is still that if all of those are shallow, then it is very
easy for the only location which has those revisions to disappear.
|
| The branch would still be mostly functional without all revisions anyway
| so this wouldn't be such a big problem. I think making retrieval of the
| revisions a background process while allowing users to commit
| immediately should be the default. You could have an option to retrieve
| all revisions first but I don't think it should be the default behavior.
| There is only one problem with DVCS that does not exist for centralised
| VCS: That is the time to branch is proportional to the size of the
| history. If Bazaar can eliminate this by default it would be simply
| awesome!
I can see the pragmatist versus the history purist showing up here. Having a
branch working for commit is not the same as preserving the history of a project.
Having come from Arch, where all branches were "shallow", it certainly became an
issue as development progressed. Yes, you could always make new commits, but it
became very difficult to find old revisions when the number of contributers
increased beyond just a couple.
Now, Bazaar certainly already has better core functionality for avoiding that,
as each copy can have more than the minimal set of revisions.
|
| It would be nice if this daemon process could embed itself in the system
| tray too. You would see progress bars for how much history is still to
| be retrieved for all you branches. You could always wait until all
| history is there before publishing your branch too - so the chaining
| issue would be no problem in that case. But at least you could start
| work right away.
|
| Cheers,
|
| Nick
I'm not sure that bringing in a Daemon is the correct fix for this sort of
thing. I think it might fit well with an integrated gui like TortoiseBZR, but I
don't think it fits well as a generic solution.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH2AFSJdeBCYSNAAMRAvPZAJ0Q4y4JobG6oyFiJq4JIcv3Bt3yQACdHYFh
CVZXZ1OsN2gkhPehqtgDJuU=
=3J9F
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list