On Tuesday 07 June 2005 13:54, Fabio Miranda Hamburger wrote:
> Hello,
>
> We have implemented SVN in our web development team. We have a
> directory called /usr/respositories which has a directory for each
> project. We did smthg like:
>
> $svnadmin create /usr/repository/project-foo
> $svnadmin create /usr/repository/project-bar
> $svn import /apache/foo/public_html file:///usr/repository/project-foo
> $svn import /apache/bar/public_html file:///usr/repository/project-bar
>
> I have the following questions reagrding this situation:
>
> 1. Is a good practise to have a repository for each project if they
> dont share files ?
This is entirely up to you. Personally, our company puts logically
separate projects in separate repositories.
> 2. Does this model make sense? Now, each developer has to 'checkout' a
> project in their hgome directory, make changes, and then 'commit', but,
> what if he remove a function that another developer, doing somthg
> similar, actually need it ? If the project manager is the only person
> able to 'commit' changes how to manage the web developer changes that
> some of them are accept but other dont.
Nothing can replace the communication that needs to happen between
developers. If A is affecting something that B is doing, then they
should be talking to each other about that change. In practice, the
model used by CVS and Subversion works very well. I know when we made
the initial jump years ago, it was somewhat frightening. In the end,
we've found that the commit and issue mails really help to improve
communication between developers.
> 3. Regarding project manager role, how to implement a hierarchy of
> users? Or, better, are the changes handle by revision, so, if the
> developer A commit bad code, and B commit good code, then, I take
> revision from B and how to avoid A commited code?
I'm not sure what you're asking here. I think you're trying to ask 2
things. The first question seems to be is it better to have someone
serve as a "patch" or "commit" manager, rather than have developers
commit straight to the repository. Personally, I think developers should
commit their code to the repository. It makes the username of the blame
output more useful, and avoids funneling all of the commits through a
single person. Often times, that turns into a bandwidth problem, where
the person is already overloaded with other work, and is incapable of
keeping up with the number of patches coming in.
The second question seems to be related to changesets and revisions. One
of the practices that I've trained our developers to follow, and follow
stringently, is the idea that a commit solves 1 particular problem (a
changeset). It's hard at first, because when you see problems, you want
to fix them. Instead, I've encouraged them to file an issue instead.
It's a tough habit to get into, but it's worth the effort. The end
result of all of this is that it's easy to back out changes. If you get
into the habit of committing changesets, then it's very easy to roll it
back when you have a problem. It's just a simple 'svn merge -rY:X; svn
commit'
> Sorry for the confusion, too many concepts at the begining,
No problem. I hope I managed to answer most of your questions.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 8 00:40:43 2005