Branching, versioning misc questions

[Fabio Miranda Hamburger <fa...@ns.isi.ulatina.ac.cr>]

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 ?

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.

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?

Sorry for the confusion, too many concepts at the begining,

Thanks in advance,

fabio.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Branching, versioning misc questions

[John Szakmeister <jo...@szakmeister.net>]

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

Re: Branching, versioning misc questions

[Fabio Miranda Hamburger <fa...@ns.isi.ulatina.ac.cr>]

Please, can anyone comment anything about the above posting. Many people
in the list will appreciate it:

> 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 ?
>
> 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.
>
> 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?
>
> Sorry for the confusion, too many concepts at the begining,
>
> Thanks in advance,
>
> fabio.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org