Daniel Berlin wrote: > >> > >> > You can't mix svn and svk commits against the same repo. It confuses >> > svk (not svn). >> > >> > You can use svk readonly, of course. >> >> Actually, that's not quite right. While svk's depot must only be used by >> svk, the usual usage is to mirror a regular subversion repository with >> svk into a svk depot, then work with it from there using svk. Any >> changes in the svn repository are pulled in with svk sync, and any >> changes to the mirrored copy are applied to the backing subversion >> repository. >> > > Except that http://svk.elixus.org/?SVKFAQ > > says "Given an svk repository, do you have to use it via svk, or can you > use svn programs to access it? > > Short answer: svn programs that only read the repository are working > fine; those who actually write in the repository would bypass svk and > make it fail. > "
Right - using svn programs to directly modify the svk depot (which is it's local 'repository'), is touchy. You *can* do it, but you have to be quite careful about the svk:* properties used to track merges and mirrors. Generally there's no need, other than perhaps using a read-only client to make your local work visible to others prior to pushing it upstream. However, none of this doesn't mean you can't use svk as your local client with a normal svn repository mirrored into the depot. In fact, it's probably the most common use of svk. This is *not* a readonly setup, as svk knows how to push commits through and back to upstream. Obviously this can entail conflict resolution if your local mirror has become a local branch, since svk also allows you to make commits that you haven't pushed back up yet, but that's not really different than still having it all loose WC without a local VCS.
