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?
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.
However, I think we are talking a little at cross purposes. My scheme
(and the SVN::Notify::Mirror modules itself) assumes that *all* changes
occur on trunk (or a branch) and that tags are immutable. You would
never directly change a "release version", but rather you would apply
the fix and create a new "release version" instead. Subversion also has
this methodology, in that if during the period between release candidate
and release anything changes, a new release candidate is created with a
unique name, rather than reusing the original RC name.
> Respect to John's solution I am not sure to understand.
> Since SVN::Notify::Mirror "Keep a mirrored working copy of a repository
> path" I suppose we lost history of release versions. Isn't it?
> I will investigate more SVN::Notify:Mirror since I am a bit lost about
> its operation.
SVN::Notify::Mirror never does anything except reflect what is in the
repository (that is why is called Mirror ;-), so you can never lose
history (as long as you proceed as I described above). Granted, the
original reason I wrote the code was to keep multiple webservers up to
date with the repository, this might not completely describe your usage
pattern...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 1 16:27:13 2007