[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Encapsulating internal diffs?

From: H. S. Teoh <hsteoh_at_quickfur.ath.cx>
Date: 2007-05-17 23:49:38 CEST

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?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 17 23:50:31 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.