RE: Re: Repositories organization

Thanks for all the replies!

Now I have to figure out how to integrate all of your ideas with our
project management software in order to achieve the necessary automation
of the process.

Thanks again.

-----Mensaje original-----
De: Bicking, David (HHoldings, IT)
[mailto:David.Bicking@thehartford.com]
Enviado el: lunes, 01 de octubre de 2007 19:19
Para: John Peacock; Gonzalez Diaz, Xoan
CC: Ryan Schmidt; users@subversion.tigris.org
Asunto: RE: Re: Repositories organization

> -----Original Message-----
> From: John Peacock [mailto:john.peacock@havurah-software.org]
>
> Gonzalez Diaz, Xoan wrote:
> > I think the idea from Ryan could be a solution ... but I am
> thinking
> > in the case that we have to modify the latest release
> version due to a
> > critical error, while some programmers have working copies
> with some
> > changes (perhaps on the same files that the modified ones on the
> > latest
> > release) not commited to trunk. If we modify directly the latest
> > version to solve that critical error, then we could merge
> the changes
> > into trunk. But how the other programmers would be affected?

If, at the time of release, you created a TAG from the trunk, then you
have two easy and reasonable approaches to avoiding any conflicts with
the "trunk" developers.

1. you make this TAG a branch by modifying it with the appropriate
changes, TAG it, then merge those changes into the trunk. Anybody who
has work in progress might need to make changes when they "update" and
find the patch affects them. That's part of their job. More than
likely, there will be negligible impact. The only problem I have here
is that if you decided initially to make a TAG, you should move that
into branches. I'd rather just branch at the point of preparation for
release.

2. create a branch from the tag, do your work, merge the changes into
trunk, tag your new release.

I strongly encourage you to consider "branch by task" methodology. In
this case, the task would be "release" or "release-only work, so the
trunk can change freely". I'd go through QA, Release, and ProdFix on
this branch, tagging as needed, and merge things back to trunk as
needed.

>
> There is nothing a version control system can do if you don't
> have good communication with your developers. If you make a
> critical change, you need to communicate that with everyone
> who might have files based on what you changed. And then it
> is up to those programmers to update their WC and resolve any
> conflicts with their local changes.

Come over to my office and convince my peers of this. I seem to be
having a great deal of difficulty doing so myself. Everybody expects
the software to track when anybody is working on "their file" while they
do so.

Several otherwise bright developers are convinced that they "need" to
have a server that lists who has what for edit, which means we're likely
going for a "check-out" model product. After all "you never know who
might be working on it for some other project". *shudder*

--
David
************************************************************************
*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is
strictly prohibited.  If you are not the intended recipient, please
notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************************
*
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org