Git : SVN plugin

[Dariusz Piatkowski]

Has anyone here tried (or succeeded in) installing the SVN plug-in for the Git system?

I have Git 2.11.0 installed and wanted to pull some source from several SVNs repos. Instead of installing SVN as a separate version control system I figured I would just try to utilizes Git instead.

However, to do so you need to install git-svn and that's where I'm running into a problem, a pre-requisite is missing and unfortunately trying to install it causes another error which I can not figure out.

Specifically, git-svn has the following dependency: perl-Git-SVN.noarch 2.11.0-4.oc00, which in turn shows this final error:

Code: [Select]

...
dependency: perl(SVN::Core)
 Unsatisfied dependency
dependency: perl(SVN::Delta)
 Unsatisfied dependency
dependency: perl(SVN::Ra)
 Unsatisfied dependency
...

What does "unsatisfied dependency" mean? How does one deal with this? Or is this a case of the RPM package itself having the wrong configuration?

I have no idea what is provided by the problem packages, but is this a case where perhaps I could try the RPM '-nodeps' parm?

Thanks!

[Valery Sedletski]

git-svn is broken and never worked, so no way

[Dave Yeo]

git-svn is broken and never worked, so no way

Only on our platform or all platforms?
To me it looks like the dependent modules could be built from CPAN, unluckily it has been so long since I built any modules that I forget the procedure though back in the day, it worked well.

[Dariusz Piatkowski]

Hmm, alright, so for what it's worth I am thinking an install of SVN will get me places faster.

A while back I grabbed SVN 1.7.21 from Paul's site (unable to get to it at the moment to check for updates). The official SVN (http://subversion.apache.org/docs/release-notes/) is up to 1.14 level now, with 1.13 being classified as production release.

Are there any plans to at least get us party further than our 1.7.x release?

For what it's worth the RPM package is even older 1.6.16.2.

[Andi B.]

IIRC correctly if you check in with 1.7 you can't check out with 1.6 anymore. Think you can't use our SmartSVN afterwards too. Maybe I'm totally wrong here and someone else knows the details.

[Andreas Schnellbacher]

IIRC correctly if you check in with 1.7 you can't check out with 1.6 anymore.

The format of the metafiles has changed with 1.7. There exists just a single .svn dir in the main dir of the local repository. sqlite is used to save the data. I use it since years (as client) without problems.

The first time, 1.7 is used for an older local repository, it asks, if it should be converted.

If you downgrade versions, it's always possible to clean the repository and check out again. I've no experience with SmartSVN, because I don't like the overhead of a JAVA app (shared mem). svn.exe suffices for me.

[Andi B.]

I've no experience with SmartSVN, because I don't like the overhead of a JAVA app (shared mem). svn.exe suffices for me.

As always with GUI programs compared to command line utilities you do not have to remember all the command line switches. Moreover the built in compare and merge utility makes it worth to use such GUI tool. As we don't have something similar to Tortoise SVN/GIT the best options for people who prefer a GUI for such tasks are SmartSVN and SmartGit on our platform TTBOMK. And I've to say these two work quite stable here with since years.

Thanks for your explanations about svn versions. I always thought if a repository is upgraded once you can't go easily back. That's the reason why I stay with SmartSVN6.6. Maybe I should start using SmartSVN7.0.7 now.

[Andreas Schnellbacher]

I always thought if a repository is upgraded once you can't go easily back.

That's the case, but the change is only locally.

BTW: I use KDiff3 for merge and compare (and DataSeeker for searching). And I have another tree beside the repository for testing. That allows me to compare files on disk (between the work tree and the src tree of the rep.), until I check them in. In special cases I have to use svn with the -r parameter to work with a special revision, but just seldom. I agree that, if I'd work with the local rep. directly, my non-SamrtSVN variant would be much harder.

[Dariusz Piatkowski]

I deployed Paul's release, will give that a spin.

Re: GUI clients...makes sense you guys. I do have a coding editor already that I use for all my projects, that being Visual SlickEdit. It has  the version control framework already in place, although of course it is up to you to configure the client specfiic things. Our OS/2 version is ancient by comparison to the modern releases, so as is to be expected those newer versions support the numerous CVS, SVN, Git, etc. right ouf-of-the-box.

[Lars]

I've no experience with SmartSVN, because I don't like the overhead of a JAVA app (shared mem). svn.exe suffices for me.

As always with GUI programs compared to command line utilities you do not have to remember all the command line switches. Moreover the built in compare and merge utility makes it worth to use such GUI tool. As we don't have something similar to Tortoise SVN/GIT the best options for people who prefer a GUI for such tasks are SmartSVN and SmartGit on our platform TTBOMK. And I've to say these two work quite stable here with since years.

Thanks for your explanations about svn versions. I always thought if a repository is upgraded once you can't go easily back. That's the reason why I stay with SmartSVN6.6. Maybe I should start using SmartSVN7.0.7 now.

I started using SmartSVN 7.x a long time ago with the USB driver repo at Netlabs and it worked without any apparent problems. I don't know if Adrian had converted the repo to the new SVN structure in any way. Or if the SmartSVN client initiated the conversion...

[Lars]

I always thought if a repository is upgraded once you can't go easily back.

That's the case, but the change is only locally.

BTW: I use KDiff3 for merge and compare (and DataSeeker for searching). And I have another tree beside the repository for testing. That allows me to compare files on disk (between the work tree and the src tree of the rep.), until I check them in. In special cases I have to use svn with the -r parameter to work with a special revision, but just seldom. I agree that, if I'd work with the local rep. directly, my non-SamrtSVN variant would be much harder.

That is what branches are for. I have used that extensively in the past. You create and switch over to the branch. Once you are done with your changes,you merge the branch into the trunk,switch back to the trunk and remove the branch (or discard the branch if you don't like your changes).
Branches have very little overhead and avoid the need to have two file trees to worry about.
As a bonus SmartSVN has a built in graphical diff ( and also merge) tool that shows you what changed from one check-in to the next. I have also used this extensively to revert changes that I had done that broke something else....

[Andi B.]

Triggered by this discussion I tested (again) SmartSVN7 with a real big software project. It started to convert the local repository but didn't finish. It took a while until I discovered that my data partition with all my programming projects run out of free space and that's the reason SmartSVN couldn't complete the conversion.

After freeing some space I now know (again) the real reason why I stood with SmartSVN6 since years - my license is only valid up to version 6 :-( Now I've a only partially converted big, and I mean real big, project which I can not handle fully with SmartSVN7 (the PRO features are disabled) and I can't handle it anymore with SmartSVN6 cause it complains about directories which are under control of a newer SVN version :-(

Time to check my backups.

Sorry for being off topic - just a reminder, sometimes there are good reasons to stay with good old proven software instead playing with new one.

[Lars]

I seem to remember that my SmartSVN 6.x license also works with SmartSVN 7.x as Roland Bill had prepared it from the generic Java package (including starting batch file and such). But it is limited to V 7.something ( I will need to look).
Just try and import your 6.x license file into the 7.x client.

[Neil Waldhauer]

I am using the free version of SmartSVN 7.07 to maintain the source code for PMMail. I also use Visual SlickEdit as my coding editor.

I don't remember what version of SVN the VOICE server is running.