+1 for repo per client. Some of my clients want access to their code,
so this makes sense.
However, sometimes I have projects for which I need to provide access
to outside contractors. In such cases, I set up a repo per project.
--
Kevin Powick
--~--~-~--~~~---~--~-
That also works. The reason that use separate repositories is so that
work for separate clients is never intermingled together, and it's
simple to control access to a particular client's work. (Companies
tend to not like their IP to be freely available to other clients,
competitor or otherw
On Jul 7, 7:42 am, Mitch Cohen wrote:
> They are scattered all over my hard drive (organized by client)
Wow, you let your client organize your hard drive? :)
Oh, yes, I'd vote for one client = one repo, too. That's how we do
it; keeps a balance between too many and too few.
--~--~-~--
The setup I use is a single repository with folders for each client
underneath a folder for each project for that client. No need for
multiple repositories. You can check out a working copy of any project
anywhere you'd like. Network congestion, e.g. checking status, can be
limited if you do this