we commonly see a need with many teams to collaborate with other teams,
with one using a customised version of the other's component. Today,
this can be done by working either (a) inside a single repository and
using branching and merging or (b) in separate repositories and using a
structured approach such as 'vendor branching' . While the former
gives users the full version control functionality, there commonly are
(non technical) reasons for wanting or needing to work in separate
repositories. In the latter approach, the challenge is how to maintain
a set of customisations, or patches, on another team's component in a
controlled, reliable (and, arguably, therefore automated), and easy/low
effort manner. The current functionality relies on the svn_load_dirs.pl
script to reconstruct structural changes such as adds, deletes, and
renames upon importing a new code drop.
Alternatively, one could augment the standard patch format, as first
devised by Larry Wall in '85, to cover *all* aspects of a data set in a
(Subversion) repository: So textual changes as well as (a) binary
changes, (b) structural changes, and optionally (c) Subversion specifics
such as versioned properties. This would improve the 'vendor branching'
mechanism by no longer needing to fetch a complete tree and then running
the script to reconstruct structural changes but enable taking a
complete diff of two versions of a data tree in a source repository that
can be applied to a data tree in a destination repository. Effectively,
this would mimic the same approach as Subversion's merge provides
without considering ancestry.
Would you find this valuable or does the current approach suffice? I
see there is an svnpatch-diff branch  which seems to be about this
topic but the note  is not really finished so I was wondering how
close the aim of that branch gets to what I described above?
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-23 15:19:06 CET