This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
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.