newbie first contact, init--repos init and documentation clarity

Hi! You asked a lot of good questions, and I appreciate the effort you
put into clearly describing how things appeared to a first time user,
this is very valuable. I'll only address part of your question here:

xVaultX wrote:
>
> PS : since I am a paranoid schizophrenic developper and I have multiple personality disorder (a geek ?) I think that the bzr whoami command should be project/repos specific and not global as it seems to be in the doc :).
>

I agree with you, I have different roles on different projects, and want
my committer email address set differently on different projects. The
good news is that this works, and I believe we should file a bug to make
the whoami command expose this functionality more clearly.

When you run bzr whoami, it sets/checks the email address that is stored
in ~/.bazaar/bazaar.conf. You will see something like this:
[DEFAULT]
email = Elliot Murphy <email address hidden>

This is a global setting. However, I can override the setting for
specific locations on my hard disk (certain projects). For example, I
keep all my work for canonical underneath the ~/canonical directory, and
here I want to use my work email address, not my personal one. So, I
made an entry in ~/.bazaar/locations.conf that looks like this:
[/home/emurphy/canonical]
email = Elliot Murphy <email address hidden>

My normal machine is configured that way, and the correct email address
is used when I commit to each different project. However, it is
confusing because the bzr whoami command always reports the global email
setting, even if I run the command from within the ~/canonical
directory. So, I believe you should file a bug asking for the bzr whoami
command to be enhanced to report both the global email address *and* the
email address that will be used if you commit in the current directory.

Hope this helps, and that you enjoy using Bazaar!
--
Elliot Murphy | https://launchpad.net/~statik/

ok

I finished the user-guide and continued to note what struck me as unclear or where the answer were coming "to late" for my thought process.

I will try to continue explain what struck me as odd or unclear in the great Bazaar.

I think that having that explanation from a newbie point of view or explain what I think would have helped me to get a grasp beyond the theorie could be useful. you are a newbie only once ;) and either you go away or you progress.

Obviously we would want most people to do the latter and not the former :)

Let me state that I get this far and took the time to explain my feelings and troubles because the documentation is ALREADY GREAT and the PRODUCT ROCKS already.

It is not a criticism of how bad it is (it is not bad), but more a suggestion about the few "missing" percents that could win lots of "newbies" . You know the 80/20 rule. 80% of the work will only get you 20% of your target and in the vice versa :).

I hope it will help clarify some of the questions a newbie can ask oneself and that could prevent him to dive into bazaar in confidence.

=============================================================================

I would love to have more explanation on
 "What is Bazaar (beside a DVCS)"
in a more concrete way besides the abstracts.I try to explain here what I understood

Bazaar is a set of data layout and protocol to manage version control.
if you have someplace such a set of files (tucked in a .bzr directory on the root of your repository) and you can file access it then you can do Version Control with that base.

Bazaar as no special server and does not give a special role at first to one such repository.

That means that your repository can be local, on the same place you have your source files, or local on another directory, or on a file share, or accessible through the web (via webdav for write access), or through FTP or SSH.

You can be one or many to "sync" with an elected "main" repository and put yourself under a few constraints that emulate centralized VCS system. Or you can do a "peer to peer" aka distributed VCS :
  user A =SSH sync=> user B ==FTP sync=> user C =SSH=> user A.

Or you can sync with user B and user C to merge changes they both made and committed to their "branched" source set.

==> I could have then Followed with more ease the great explanation on the workflows (1.3) and then the chapter 4, 5 and 6 that explain the possibilities in more details.

**** Is that right **** ?

=============================================================================

There seem to be a confusion on the meaning of branch : it seems to represent both an ordered set of revisions and the actual working files that you got when doing the bzr init.
Maybe is there the need for one more term like "working set".

The theoretical distinction between a repository and and a branch is fine in theory but unclear in practice, hence the confusion beetween bzr init and bzr init-repo that is still in my mind.

I will try to explain what I understood.

A repos is a local data store or the copy of a foreign data store.
A branch is some extraction from the repository with the changes sets that occurred since that extraction (could be null after a complete merge/commit)

So you can only Branch FROM a repository. (need explanation of what happens when you just do bzr init like in 3.2.1, why is init-repo not needed in this case)

You do not need (and most of the time should not) mix your repos with your branches, you could have a repos without working files (your documents or source code or whatever you are versioning) in some place (you build it with the --no-trees option of the bzr init-repo command) and the branch you are working on in another place under another directory. (right ?)
You can have many branches extracted from the same repository and work at the same time on all of them and merge/commit at any time resolving conflicts if they arise.

**** Is that right ? incomplete ? **** ?

=============================================================================

 "central repository and the pull command "

Coming into part 5 I found the model I wanted to use with a central repository accessible on a shared server.

But yet I was confused by the vocabulary (5.2.2):
"There are two ways of populating a central branch with"
wait .... is it a Branch ? or a Repos ?

Then what does really the "push" command ? just a copy all of the local repository it is applied on (erf it is in fact a branch then because we did bzr init-repos and then bzr init).

in the second way (making an empty central branch and then committing content to it) there seems to be some magic done by the checkout command and indeed the next chapter hint that the first way of making the central repository (Making a local branch and pushing content to it) is incomplete before maling a bind.

Really confusing when concentrating on reading 5.2.2 :)

I will try to explain my thought process reading "the second way example"
* We do a LOCAL repos
* We switch to it
* We then do a "foreign" CENTRAL BRANCH (and not a repos why ?) that somehow use the repository directory name we used in the first step
* We do a magical CHECKOUT command I do not really understand at this point that seems to create a branch, maybe local maybe foreign maybe both
* We switch locally to the branch (so checkout must have created it)
* We populate the local branch with the working set
* We add the file to the version control
* we commit the add and it seems to commit toward the foreign CENTRAL repos/branch because of the checkout command.

As you can see there is a lot of "blur" and implicit things when reading and One
lacks the "why" or the precise role of each command.

What I understood , maybe wrongly is that the bzr checkout command TIES and implies some constraints beetween two repository :
- one become the "master"
- committing to the master implies committing to the local
- but you can commit local and not yet to the master ? (*** right ??? ***)
- you can change your master / reference repository (branch ) with the bzr bind command at any time ?

In a way the bind/checkout command create a tree stage structure, an "arbitrary main repository", a "local repository" and the branches you choose to derive from that. (you can ammend that with lightweight checkout an such but let's understand the basics before the details :) )

Checkout is a command you do to tie yourself to a foreign repos from that repos point of view, that mean you will get back its structure, history, changelog and working set from the command. (then you can populate it and commit to get stuff into it)

Bind is the command you do to tie yourself to a foreign repos from YOUR "point of view", are the effect the same as the checkout ? or will that wait for the next Merge/commit to have your difference resolved ?

This post is already quite long and I will stop here, not knowing if it is the right place for such things.

There is still a few other places that were unclear to me after reading the manual and I would love to continue explain these if it useful, before I hopefully, understand it all and my newbiness goes into the oblivion of "I got it or so I think", if it is useful of course :).

This question was expired because it remained in the 'Open' state without activity for the last 15 days.