[NBP web-reskin] (3) More ID's needed

[Ethan Rowe]

Didomenico, Steven wrote:
> After I log into a camp, I can update HTML files "in place" or FTP a
> file I created or modified. I'm okay with this part. 
> 
> I make a new file or a change and I then "commit" to Git.
> When I add the code to the camp, it appears to be live.  Is this true?
> Or does it have to moves somewhere else or does Git do this?

Let me clarify a few things:
- each camp is a Git repository.
- this means that commits in a camp are to that specific repository
- each of these camp Git repos are cloned from a master repository that
is specific to this reskinning project
- this means that each camp repo's "master" branch tracks the master
branch of that master repository
- the Interchange and Apache instances within a camp run off whatever's
in the camp's files; therefore, a specific camp, when viewed through a
browser, reflects the state of the files/data in that camp, and has no
correlation with what's committed and what is not committed
- to accumulate the team's work in one place and work with each other's
changes, you have to "git push" your committed changes from your camp;
this pushes those changes up to the master repository; furthermore, you
have to occasionally "git pull" to get the latest changes from that
master repository pulled into your camp

I've set up the master reskin repo so upon receiving new commits it will
email this list so we're all informed and can inspect the patches.

Please note that these patches are going to be extremely noisy unless we
can all agree to use the same line endings in our editors.  Are you all
working with a particular OS and editor?

> I think this is the link you sent in an earlier email. I take it the Git
> commands are available here.
> 
> http://git-scm.com/
> 
> I understand the multiple camp plan you talking about. Is this how you
> envision the camps?
> 
> Camp26 - current nbp.org source code used for template training
> Camp27 - empty - Developer # 1 
> Camp28 - empty - Developer # 2 
> Camp29 - empty - Developer # 3 
> Camp30 - empty - Developer # 4

Yes, excluding the camp26 thing.  You can do whatever you want with
that.  It might make sense to use it as a staging camp; you don't do
development work there, you only pull in the latest stuff from the
master repository and use it as the official testing/staging ground.

As Edie has probably mentioned, you'll be able to get at each camp's
running application through your browser by going here and following the
appropriate link:
http://camp.nbp.temphost.net/

Each developer should, when first starting to work with his/her
respective camp, shell into the account, cd into the camp directory, and
execute the following commands:

 git config add user.name 'Your Name Here'
 git config add user.email 'your at emailaddress.com'

This will ensure that the proper name/address show up in the commits
done in that camp.

> Camp26 does not allow Git commits. A Git commit from Camp 27 - 30, will
> update one version control environment, one Git.

Nope.  See my comments above.  :)

> As we go along, it will be the developers responsibility to get the most
> current source from the one Git into their camp.

Right, but as long as people push their commits upstream, as discussed
above, this is pretty simple.

> Anyone else have comments?

I would note that with Git in particular, since your commits are local
to your repository until you decide to share them, it's a good practice
to commit pretty early and often.  If you do frequent "git pull" calls
when you have uncommitted changes in your camp, you'll end up fixing
merge conflicts as you go and generally find it to be a pain, resulting
in a messy version history.

It's a pretty good practice to commit what you're doing as you go, in
small increments, with suitable commit messages.

I hope this helps.

Thanks.
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com