I’ve been working on a new 2.0 version of Community Auth, and it’s substantially different than the 1.X version because roles all have their own profile tables in the database. In the 1.X version roles all share a user profile table. Having separate tables allows roles profiles to be unique. For instance, an employee doesn’t really need a shipping address, but a customer might. An employee might need to be in a department, but a admin shouldn’t be restricted to a department. By creating separate profile tables, each role can be easily customized.

What I’ve always done is work out of a directory in htdocs on my dev machine. When I want to commit, I copy the files to the repo, commit and push.

Although I haven’t created the 2.0 branch in the repo yet, I’m ready but I have some questions.

1) Is it standard practice to work out of the repo, or is it “normal” to work out of a different directory and then copy, commit and push? (The way I’ve been doing it). The reason why I’m asking is it seems like a lot of work to do what I’m doing, but working straight out of the repo seems risky for some reason.

2) I don’t know that I want to abandon the 1.X version, meaning I don’t know that I would ever do a merge and be done with 1.X. In this case, is 2.0 a branch, or should it just be a separate repo? I’m not really sure it’s worth hanging on to the 1.X branch, but should I decide to keep working on it, I just want to do the right thing.

1) you are wasting your time. If you don’t want to work straight on master, create a working branch for the day & just merge as you are ready. a simple checkout can swap you back and forth between work views

one thing I’ve been working on a lot lately is efficiency in my workflows, from Sublime Text snippets to git aliases. once you start, you’ll think: God, how much of my life did I waste doing things the stupid way?

2) I would personally make a separate repo & consider them to be completely different projects, but there may be other ideas for this

Always work out of the repo. As jmadsen said, if you’re worried about affecting a current version, create a branch and do what you need. If you want to merge it back at that point, it’s easy. You might want to look into Git Flow, also. https://github.com/nvie/gitflow Helps with features and version releases, or may just give you some better ideas at optimizing your own work flow, even if you don’t use it. But yeah, there’s no reason to copy files into a repo when you can modify them directly. Inevitably, you will forget or overwrite something and your flow - and potentially your product, and customers’ websites - will be screwed.

A separate repo would help differentiate the two versions, if you want to show it more as a separate release / new product, rather than an upgrade. You could just use different branches in the same repo, also. CodeIgniter has different branches for its versions, but then again, CI’s legacy version is always maintained (IE 2.1.x is still receiving bug fixes while 3.0 is being developed).

Thanks for your responses. I do have another question related to working directly from the repo. What are you doing about your local configuration? DB settings, encryption key, etc?

I typically use a localhost dir on config/ & gitignore it; that way it doesn’t go up & others can have their own localhost setting. then we share development, testing, etc as appropriate

jmadsen - 05 October 2012 04:58 PM

I typically use a localhost dir on config/ & gitignore it; that way it doesn’t go up & others can have their own localhost setting. then we share development, testing, etc as appropriate

OK, I guess I should have read the user guide about config environments. I use both git and mercurial, and they both have the ability to ignore. Thanks.

it takes a while to get everything you the way you like it - I did it exactly like you are, just saying, “I want it to be like this..” & googling and asking how to do that.

RTFM? You must be kidding. I don’t have time for that

Yeah configs depend on how public your repo is. Obviously if you have a private repo with only you having access, credentials aren’t too big a deal. Pretty easy to specify what you do and don’t want to share.