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

Re: Transaction building with bindings, do I need a WC on disk

From: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-02-24 05:59:01 CET

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.


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

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