Encapsulating internal diffs?

["H. S. Teoh" <hs...@quickfur.ath.cx>]

Hi all,

About 2 years ago, I managed to convince the company I work for to
switch from CVS to SVN. It has been great, except that the way things
work around here doesn't quite jive with the way svn was designed to
work. As a result, once in a while nasty problems still come up, mostly
involving broken file ancestries.

Basically, the developers do not ever commit to the trunk, but submit
diffs to CM, who does the commit on their behalf (after the necessary
review/approval process, etc.). This isn't usually a problem as CM has
developed a set of tools to handle adding/deleting files, etc., so we
can still take advantage of directory-level versioning, added/deleted
files, and so forth. However, renaming isn't supported, because there is
currently no way (that we know of) to encapsulate an "add-with-history"
operation in a diff external to the repository. This leads to files and
directories with broken ancestries, which eventually cause nasty sync
problems during branch merges (e.g., file X gets added in branch, then
gets added without history to trunk during branch merge #1, but
development continues in the branch, and before branch merge #2, syncing
to trunk causes a conflict on X, and during branch merge #2, X causes
conflict in trunk --> merge nightmare).

Any suggestions as to how to improve this? The CM process is
unfortunately unlikely to change---they still want us to submit diffs
rather than have direct commit access. But it would greatly help things
if there is a way of encapsulating a diff that effectively tells SVN,
"file X is actually derived from internal_url#1, so when adding please
reuse the history from that URL". Ideas?


--T

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

Re: Encapsulating internal diffs?

[Andy Levy <an...@gmail.com>]

On 5/17/07, Olivier Dagenais <ol...@formark.com> wrote:
> > Any suggestions as to how to improve this? The CM process is
> > unfortunately unlikely to change---they still want us to submit diffs
> > rather than have direct commit access. But it would greatly help things
> > if there is a way of encapsulating a diff that effectively tells SVN,
> > "file X is actually derived from internal_url#1, so when adding please
> > reuse the history from that URL". Ideas?
>
> When we switched from VSS to SVN, we also implemented a single-committer
> patch submission and review process.  When there are directory-level
> operations, they have to be documented in the change log that is submitted
> with the patch.  We use a "File operations" section that describes what the
> committer must do, usually before applying the patch or even in the middle
> of doing so. (and there is usually a small enough number of operations that
> the committer can apply them by hand)  It looks something like this:
>
> """
> File operations:
> RENAME Project/Class.cs to Project/AbstractClass.cs
> Apply attached patch
> DELETE Project/DuplicateClass.cs
> """
>
> etc.
>
> In other words, your current tools and process are almost there.   We
> recently started also using feature/task branches when there are several
> file operations as part of a commit (which was also mentioned by Giovanni).
> This approach also makes the reviews easier because the developer can commit
> as often as they want to their branch (sometimes within 10 minutes of a
> previous commit) and then the committer can inspect these changes
> individually or as batches.  We also considered making the file operations a
> batch file that executes the command-line SVN program that performs said
> operations (because there really isn't that much more work involved than
> writing it by hand) but branches are good enough.
>
> If you go with the branches approach, take a look at "authz" (which appeared
> in version 1.4, I think) if you don't trust your non-committers not to
> commit to the trunk.

It's been available since at least SVN 1.2.

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

Re: Encapsulating internal diffs?

[Olivier Dagenais <ol...@formark.com>]

> Any suggestions as to how to improve this? The CM process is
> unfortunately unlikely to change---they still want us to submit diffs
> rather than have direct commit access. But it would greatly help things
> if there is a way of encapsulating a diff that effectively tells SVN,
> "file X is actually derived from internal_url#1, so when adding please
> reuse the history from that URL". Ideas?

When we switched from VSS to SVN, we also implemented a single-committer 
patch submission and review process.  When there are directory-level 
operations, they have to be documented in the change log that is submitted 
with the patch.  We use a "File operations" section that describes what the 
committer must do, usually before applying the patch or even in the middle 
of doing so. (and there is usually a small enough number of operations that 
the committer can apply them by hand)  It looks something like this:

"""
File operations:
RENAME Project/Class.cs to Project/AbstractClass.cs
Apply attached patch
DELETE Project/DuplicateClass.cs
"""

etc.

In other words, your current tools and process are almost there.   We 
recently started also using feature/task branches when there are several 
file operations as part of a commit (which was also mentioned by Giovanni). 
This approach also makes the reviews easier because the developer can commit 
as often as they want to their branch (sometimes within 10 minutes of a 
previous commit) and then the committer can inspect these changes 
individually or as batches.  We also considered making the file operations a 
batch file that executes the command-line SVN program that performs said 
operations (because there really isn't that much more work involved than 
writing it by hand) but branches are good enough.

If you go with the branches approach, take a look at "authz" (which appeared 
in version 1.4, I think) if you don't trust your non-committers not to 
commit to the trunk.

HTH,

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Olivier Dagenais
Software Engineering / Génie logiciel
Formark - Combine the Best of SharePoint® and Livelink®
Phone: 613-599-5173 ext 238
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Make sure you don't miss anything: subscribe to the Formark Newsletter:
http://www.formark.com/support/register/index.asp

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

Re: Encapsulating internal diffs?

[Giovanni Bajo <ra...@develer.com>]

On 17/05/2007 23.49, H. S. Teoh wrote:

> Any suggestions as to how to improve this? The CM process is
> unfortunately unlikely to change---they still want us to submit diffs
> rather than have direct commit access. 

Well, depends on what you mean by "commit access".

Instead of a diff, each developer could create a new branch from trunk and 
does his/her modification in it. When the patch is ready, he just sends an 
e-mail to the CM, who just needs to checkout/switch/log the branch and decides 
if it's good or not. If it's ok, he can merge it to trunk with one simple 
command (including all the history-sensitive changes).

Otherwise, have a look at "svk", who has a way to manage a local patch queue 
for each user, and submit patches with full history information which are even 
machine-parsable.
-- 
Giovanni Bajo

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

Re: Encapsulating internal diffs?

[Jim Sokoloff <ji...@sokoloff.com>]

On Thu, 17 May 2007, H. S. Teoh wrote:

> Any suggestions as to how to improve this? The CM process is
> unfortunately unlikely to change---they still want us to submit diffs
> rather than have direct commit access. But it would greatly help things
> if there is a way of encapsulating a diff that effectively tells SVN,
> "file X is actually derived from internal_url#1, so when adding please
> reuse the history from that URL". Ideas?

Have you considered giving the development team
direct access to subversion repository Y (or
path Z within repository X) and having the CM
team using repository X directly?

I presume your development team wants to have
revision control before involving CM anyway, so
if you adopt a model like this, you may be able
to easily automatically generate the diffs and
ancestry information to feed CM from your svn
history in the development repository.

--Jim

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