Then 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'.
>
> 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've actually had a user who's playing with the javahl bindings ask
me a kind of similar question. He's *very* interested in using Subversion
as the filesystem backend for a web application. The history information
that it provides is a million dollar feature from his point of view
(until I pointed out Subversion, they were going to keep files on disc
with .1, .2, .3 extensions).
They have the situation where they would like to let users upload zip
files to update portions of the tree, via a web interface. The entire
tree is huge (many gigabytes), so keeping a working copy on disc is
a bit of a pain. In addition, most queries to the website will hit
the HEAD revision to retrieve content. When an upload happens, he
wants to be able to construct a commit_editor and commit changes
without having to have a working copy. From what I can tell, the
java bindings fall a touch short of being able to do that just now.
Another context where the "merge without WC" might be useful is in
simulating a promotional model like some other CM tools provide
(CA's Harvest is one that I've used like this). If changes can
only be made on /trunk (enforced with pre-commit hooks), then it's
always safe to merge to branches, no conflicts will arise (assuming
you ensure that dependent revisions are always merged together).
This is nice for people who want to "promote to test" without a
massive working copy.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 24 06:00:28 2005