Subject: Where is "all" data stored; so which .bzr dire may be removed? - msg#00843

Previous Message by Date: click to view message preview

Re: [qbzr] Re: [RFC] push and --no-strict and QBzr

Hello Martin, Martin Pool a écrit, Le 24.07.2009 01:48: 2009/7/24 Alexander Belchenko <bialix@xxxxxxx>: The general idea was that people would be more confused when "bzr push" didn't push what they thought they were pushing (I forgot to commit, etc), rather than having to supply a new argument when they really did want to push something out of the ordinary. There was also a strong push from MySQL. I don't know if they wanted it to be the default, they *definitely* wanted to be able to have it as the default for some people. (push_strict=True). As one of the reoccurring issues for MySQL was people pushing and not realizing that they had not committed. (I think some of this stemmed from using BK which automatically commits when you 'merge', while we require it as a separate step.) I went to the similar conclusion about this option, but I still think this change has introduced too much penalty to existing experienced bzr users, and we have to pay this price for the sake of newbies safety. I'm not agreed with such price somewhere deep inside me. I too thought it was a good idea, but I'd be prepared to change it now. Robert posted before that this is probably a case where we should notify people and make it easy to fix their mistake (by committing and pushing again), rather than blocking it. So I'd like a patch that makes it just warn unless --strict is given, and no warning at all if --quiet is given. I cc'd GuilhemB in case he wants to comment. Thanks for letting me know. From the MySQL side, I confirm I definitely wanted a way (by default or not) to prevent pushes if there are uncommitted changes. It's not only about newbies; the problem can catch experienced users as well, for example this, at late night: - change code - run tests - tests ok, commit - ahah, should also run an extra test suite - extra test suite fails - fix code - extra test suite passes, finally - push and then we have pushed some broken code, because forgot to commit the final code change. A push triggers automated tests on multiple machines (kind of buildbot), so a broken code push is annoying. I'm happy that --strict is on by default, but as other users seem to have different opinions, which may be very valid, I'll defer to Canonical folks :-) If it's made non-default then I'll advise my colleagues to put it in their bazaar.conf.

Next Message by Date: click to view message preview

Automatic setting of --author when committing a merge

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I think it would be a good idea if Bazaar would set the --author option for each author of a revision in a pending merge when committing (or at least it could be an option to the commit command to do so). That way when PQM, for example, commits on behalf of a number of authors then the authors fields on the committed revision would be correct. What do you think? Cheers, Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpi02AACgkQm69gNgxDuSHXeQCfXynpuPNaOZdzSQ40VWZhFhTX yasAn1UNFvTa2wlMsNBfaIeuMRU/7wKw =Ew8w -----END PGP SIGNATURE-----

Previous Message by Thread: click to view message preview

1.17 installation problems on OS X 10.5

Dear all, I'm having an issue with upgrading from bazaar 1.16.1 to 1.17 on OS X 10.5.7 - I'm installing bazaar from your download page (sorry, but I prefer to avoid using fink or macports). Currently, you only have 1.16.1 listed against 10.5 on your download page. If I chose either of the python offerings for an install of bazaar 1.17 from the OS X 10.4 listings, installation fails telling me I should upgrade my python to 2.5. Here's the output regarding my python versions: $ which python /usr/local/bin/python $ python --version Python 2.6.1 and if I stick to the Mac installed versions of python: $ ls -l /System/Library/Frameworks/Python.framework/Versions total 8 drwxr-xr-x 7 root wheel 238 31 Oct 2007 2.3/ drwxr-xr-x 11 root wheel 374 20 Jul 20:38 2.5/ lrwxr-xr-x 1 root wheel 3 31 Oct 2007 Current@ -> 2.5 As you can see, I clearly have (via either route) at least python 2.5 installed. Looking in the logs does not reveal anything untoward regarding attempts at installation. Any help in progressing the issue is very much appreciated, Carl.

Next Message by Thread: click to view message preview

Re: Where is "all" data stored; so which .bzr dire may be removed?

On Thu, Jul 30, 2009 at 07:41:35PM +0200 I heard the voice of ALbert Mietus, and lo! it spake thus: > > My first question: does the shared-.bzr dir also holds "all". That question can't really be answered; it's too broad (or too narrow). All bzr data goes in a bzrdir (.bzr). Fundamentally, there are 3 types of bzr entities: 1) There are revisions, the individual snapshots in the history. These go in a repository. 2) There are branches, which are basically pointers into the revision space, saying "these are the bits of history in this branch". 3) There are working trees, which are where you edit files and do stuff. The bzr data here is meta-information like "what the base revision is" and "how the unaltered files look" (speaking very roughly). (3) corresponds to the CVS/ directories in a CVS checkout, except that there's only one at the root of the tree, rather than one in each directory. (1) and (2) roughly correspond to $CVSROOT and entities within it. The primary difference to grasp from CVS is that the branch is the primary entity to be concerned with. > If so, then I should be allowed to delete all other .bzr dirs in > subdirs of that shared repository Generally, you probably shouldn't delete a .bzr dir unless you're also deleting the dir around it. > If so, how can I re-create those brances. Deleting a _branch_ by itself doesn't destroy [much] data; the revisions are still in the repository. Of course, if it's a standalone branch, the repository is in the same .bzr/ dir, so you'd've thrown that away too. If you still know the head rev, you can recreate much of the branch state and move forward. If you don't, there may be various ways to guess. > Meaning: get a working dir (the lastest version in that branch). Getting a working dir _is_ a distinct operation from getting a branch, though UI-wise they often happen at the same time. In the case of your particular layout here: > .../TryOut/.bzr This is likely to be a shared repository. All the branches within use this for their revision storage. Think of it as a giant bucket, with all the individual revisions floating around in it without any necessary structure. > .../TryOut/branches/Apple_Darkroom/.bzr > .../TryOut/branches/Apple_Goldenrod/.bzr > .../TryOut/branches/HEAD/.bzr These are three branches. HEAD would be the CVS head, and the other two would be from like-named CVS branches. If either or both of them has been merged into HEAD (which couldn't have been translated from CVS, revision-wise, but the file contents at least would be), they wouldn't have any information that HEAD wouldn't already have (technically, being a branch, HEAD doesn't _have_ any information, it just _points to_ some in the repository). But if not, they don't, so would need to be individually preserved. > .../TryOut/tags/GAM20071219/.bzr > .../TryOut/tags/GAM20080201/.bzr These are translated from CVS tags, but (due to the way cvsps-import works) are actually also bzr branches, with the head rev of each branch being the revision that the tag actually applies to (insert here necessary caevets about the actual situations CVS creates). This is sorta the same thing that SVN does with its "tags", which is wht cvsps-import sets things up like this. There's no reason these couldn't be actual tags in the branches that have those revs though, other than "cvsps-import doesn't do that". You could add them manually by matching up revids (not a big deal since there's only two). What I would do is 'branch' out the dirs from the cvsps-import--created repository into my own workspace (possibly with a shared repo there if necessary) and use them from there going forward. How you lay out the branches in that workspace is all up to you. Then I either delete or tar up the cvsps-import repo after I'm done. That's just personal preference, however; you could move the whole thing (TryOut/) into place if it's not already and work in there, I just prefer treating it as a temporary staging area for the translation. -- Matthew Fuller (MF4839) | fullermd@xxxxxxxxxxxxxxx Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.