can subversion 1.6 be made "just as distributed as git&

I have a co-worker who has suggested that, using "svnadmin hotcopy", subversion can be   just as "distributed" a system as Git    While I see how this can be done, it hardly seems to me to qualify as "just as", making this "plausible" at best.    Can anyone give me a quick confirmation of this? Confirmed? Plausible? Busted?    If this is confirmed or plausible, could someone give me a quick run-down?    (I would appreciate a response, no matter how long it takes, but I do have a meeting with this co-worker in another 16 hours... (10am Pacific).)    Thanks in advance!

Last updated 12 years ago

No, and your coworker doesn't seem to have any understanding of what svnadmin hotcopy really does.    Subversion is a centralized VCS, the extent of its "distributedness" is the ability to set up read-only mirrors of a repository with a write-through proxy forwarding commits to the master repository.    They are completely different systems, and you can't "make" Subversion "just as distributed as git", period.

Thanks for your reply! BTW - I'm glad you're watching, because in a new e-mail my co-worker replied to you.  I had copied a post you had:  

"hotcopy is only one way. It's meant to make a copy of a live repository for backup purposes. You cannot take something that's been hotcopied and merge it back into the original repository."

 He replied:  

I certainly can merge a hotcopied SVN tree back with a main. It's a shame that andyl can't, but there is nothing that makes that an impossible task. It is easier with other forms of replication (there are 3 types of replication commonly referred to in the documentation and a number of external methods as well - including the cp command which I refer to later), but a simple merge of the files work (svn diff localRevFromOld, apply patches from local to server copy, commit). Even andyl states that hotcopy is only one way, though, and it's funny because they are discussing SVK - another tool for SVN repository replication that handles just that (well, technically SVK is its own versioning system without a repository, but it is usually used with SVN to provide the repository since that's what it's usually integrated with and where the toolchain is)

   I don't mind selecting Subversion, but I want everyone to understand the choices clearly, and the arguments I am getting just don't seem to make sense.    Thank you for your quick response!

Hi,    

mdellerus

I certainly can merge a hotcopied SVN tree back with a main. It's a shame that andyl can't, but there is nothing that makes that an impossible task.

[/quote]  I wouldn't call it a merge, cause it will be just a patching nothing more. There is no relationship to merge neither a recording of merged things from an other repository. So Andyl is absoluteley correct.    

mdellerus

It is easier with other forms of replication (there are 3 types of replication commonly referred to in the documentation and a number of external methods as well - including the cp command which I refer to later), but a simple merge of the files work (svn diff localRevFromOld, apply patches from local to server copy, commit).

[/quote]As described above...but no recording of merges ...    

mdellerus

Even andyl states that hotcopy is only one way, though,

[/quote]  And he is right. in the meaning to make a copy....    [quote=mdellerus]

and it's funny because they are discussing SVK - another tool for SVN repository replication that handles just that

Sorry to say that in a harsh way, but SVK is not tool for repository replication it's a distributed version control tool.    [quote=mdellerus]

(well, technically SVK is its own versioning system without a repository,

This is also wrong. It has it's own repository which is usually located $HOME/.svk/local which is indeed a subversion repository, cause SVK is written in Perl which uses the Subversion Perl bindings.    [quote=mdellerus]

but it is usually used with SVN to provide the repository since that's what it's usually integrated with and where the toolchain is)

There is no way to use something different as SVN bindings in SVK.    If there is a real need for DVCS you can use git via the git svn bridge to clone a branch etc.    Kind regards  Karl Heinz Marbaise

I'd argue Subversion is more distributed than git because of the MultiSite tools available. If I had 10 development teams around the world I'd much prefer they all had a copy of the entire repository and were continuously integrating rather than doing occasional git merges and resolving loads of conflicts in batches. Also doesn't hurt to have hot backups all over the world in case of a hardware / network failure.

How about this...    1. Use "svn sync" to copy central repository "C" to a local one "L".  2. Use local repository "L" for all kinds of work.  3. To perform an update, use "svn merge" to merge "C" into "L".  ....a. Checkout from "L" into workspace "w".  ....b. Use "svn merge" to merge from "C" into "w".  ....c. Resolve any difficulties with the merge.  ....d. Commit the changes from "w" back into "L".  ....e. Repeat as necessary until all desired branches are updated.  4. To commit changes to "C"...  ....a. Checkout from "C" into workspace "w".  ....b. Use "svn merge" to merge from "L" into "w".  ....c. Resolve any difficulties with the merge.  ....d. Commit the changes in "w" back into "C".  ....e. Repeat as necessary until all desired branches are committed.    I don't like it, but would it work?

You can't merge between repositories (you could do something hacky with svn diff & patch but it wouldn't capture everything).    And even if you could, that is so convoluted that I can't see it being done properly 100% of the time. Is it worth risking your source code?