From: Muthu Gopal [mailto:muthuboy@hotmail.com]
The development team commits the changes in the repository for each change
request or defect fix. So let's say there are 3 defects affecting 15 files
( 5 files each),3 commits would be done by the development team. Out of
these 15 files, 6 may be from java folder,4 may be shell folder and another
5 from jsp folder. When they handover the sources, they ideally create a tag
and ask the compilation/deployment team to pick-up sources using that tag.
Since the compilation/deployment team would need only the files that are
changed after the last deployment (but in the same directory tree
structure), having the entire source set in the new tags would mean, the
compilation team must execute the svn diff/log commands to pick up sources,
instead of the straight forward svn update and windows copy.
I think I understand what you want to do. But that method does not work
well with Subversion, and there may be other methods that are equally useful
to you but work better with Subversion.
The first principle is to avoid doing partial source distributions --
Subversion is oriented toward looking at all the source as a unit, and is
careful to make such operations efficient. It is also advantageous when
handing source from one group to another to always hand over the *entire*
source, as then it becomes harder for the receiving group to make mistakes
when merging a changeset into their copy of the source.
The second principle is that Subversion does not handle changesets as such.
However, it's quite easy to take one tag, copy it, then back out of it one
of the changesets that is in its ancestry, and leave the result as a new
tag. (Which you then want to distribute as a unit -- see above.)
A serious complication arises if the receiving group maintains a slightly
different code base than the sending group. That is often the reason that
the receiving group wants to receive changesets rather than unitary source
distributions. But that situation offers many opportunities for error. It
turns out that Subversion *does* offer an effective and robust method for
handling such a situation, one that avoids most opportunities for error,
called a "vendor branch". If this is your situation, I would heartily
recommend a Subversion vendor branch structure, as it is the only method
I've ever seen that robustly *automates* such a situation.
Dale
Received on Thu Mar 31 16:27:29 2005