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

[Didomenico, Steven]

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?

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

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

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

Anyone else have comments?


-----Original Message-----
From: web-reskin-bounces at nbp.org [mailto:web-reskin-bounces at nbp.org] On
Behalf Of Ethan Rowe
Sent: Friday, July 31, 2009 9:43 AM
To: Discussions regarding the 2009 UI reskin of nbp.org
Subject: Re: [NBP web-reskin] (3) More ID's needed

Didomenico, Steven wrote:
> okay. as long as they all point to the same place on the web server.

They would not; they would be entirely independent instances of the
application, each with their own domain and whatnot.

If you all want to be working against the same instance of the
application, meaning the same subdomain, then nothing else need happen.
 There's no restriction on the number of concurrent login sessions for
the account.

The only drawback to having a single account is all the work would look
like it came from the same person in the Git commit history, unless when
making commits people specify --author.  Which is probably a good
practice in this case.

If we create new camps under the fidelity_camp user account, such that
each team member has one camp, that may still be best; we can configure
Git for each of those camps so the commit author appears to be the
person who works on that camp, so we know who is responsible for what
change in the version history.  Furthermore, this lets each of you work
on pieces in isolation, without fear of overwriting each other's work.
Then, you commit your stuff in a camp, push the commits upstream, and
the other team members can pull your changes in.  This is the standard
workflow for version controlled development.

Thanks.
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com
_______________________________________________
Web-reskin mailing list
Web-reskin at nbp.org
http://www.nbp.org/mailman/listinfo/web-reskin