On Feb 23, 2005, at 9:20 PM, Ben Collins-Sussman wrote:
> My reaction is: I don't understand the bigger picture, and why you're
> trying to do such complex things.
>
> AFAICT, you need to port a 'set of changes' from the trunk to N
> different release branches. Why can't you do it the normal way? Keep
> a working copy of every release branch. Run 'svn merge' on each one,
> and then 'svn commit'.
Yes, that is fine, good, and the way that I operate projects generally.
Automating the checkout/merge/commit to various releases when it is
conflict-free because the changed files are identical would match a
currently enjoyed function of the current SCM system and would help me
convince the group to change.
Yes, the group does not find out until the nightly build if these
changes actually broke the thing: the reality is that it works well
enough and breakages because of the multi-release checkin are rare
enough (platform differences account for most failures: AIX, Linux,
Sun, and HP, 32-bit and 64-bit of each, on platform 'native'
compilers).
> That's how changes get ported from one branch to another in
> Subversion. I don't see what -N checkouts have to do with anything,
> or why you're trying to copy files around between branches. I'm
> wondering if you're trying to artifically transfer a paradigm from
> some other SCM system to Subversion.
I think this is pretty generic actually.
Assume something like:
repos/trunk/
repos/release/branch/
11.x/
10.x/
9.x/
8.x/
repos/release/tag/<many tags>
Let's say a bug is found and fixed with two sourcefile changes:
src/libclient/init.c
src/util/idsort.c
Assume that those two files have been unchanged for many years and so
are identical from version 8 until trunk. Let's assume that each
release generates a 55 Mb working copy. Rather than requiring 220 Mb
of additional disk space for the branches (we already have a full trunk
WC) and transferring that all across the network (cross-country), what
if we could, for each release, just download a couple Mb to get the
src/libclient/ and src/util/ directories in our working copy (rooted
at their common release directory of course so the commit of the two
changes is one atomic commit) and avoid downloading, for example, the
25 Mb of documentation that each release contains. We'd then merge
into the limited WC which contains everything necessary for the merge.
The vast majority of changes involve < 20 files in just a few
directories (kilobytes of change). That's the common case I'd like to
try and optimize.
From a Linux server (svn 1.1.3) to AIX (svn 1.0.1 client--yes, this'll
be upgraded shortly) both within the same building, https checkout to
/tmp of the 55 Mb working copy of trunk takes ~6 minutes. (The users
I'm concerned about will be doing cross-country checkouts.)
Actually, relatedly, I'd like to be able to checkout our trunk and have
multiple WCs, each containing different changes-in-progress AND, I'd
like to exclude the documentation directory from most of them. Is
there a way to do this if the documentation is at the same level as the
directories of source? (trunk/doc/ trunk/libclient/*.c) It's nice
having the docs tightly tied to the releases like that, except for the
size of the WCs when making doc-change-free alterations.
I hope this email clarifies my questions and doesn't just heighten the
confusion. ;-)
I do admit that I changed the questions a bit from my original ones.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 24 05:18:41 2005