Re: svn vs. git
On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote:
> Since the article mentioned FreeBSD (I'm a FreeBSD developer, and I
> use both git and subversion everyday), I think I need to point out
> that the author have missed some important pain points.
>
> My biggest pain point with subversion is that 'svn up', 'svn st' and
> 'svn diff' take much longer time compared to git's counterpart ('git
> pull', 'git st', and 'git diff') for FreeBSD's base/ (src) and ports/
> (ports) trees.
>
> As a result, doing merges across branches with subversion could become
> quite painful with FreeBSD's branch usage, where branches tends to be
> diverged quite a bit (we have multiple "-STABLE" branches, and
> sometimes changes are not backported from trunk to these branches).
> Because the tree is large, 'svn merge' operation is slow compared to
> the git counterpart (git cherry-pick, except it does not keep the
> mergeinfo this way), and doing multiple merges would require the
> repository server (or a local mirror), and most importantly, if
> something goes wrong in the middle, there is no easy way to recover
> from it. Here is an example, let's say I have a list of 5 commits to
> be merged, and the first one have a conflict that requires manual
> tweaks, then I would merge 2-5, and at 5 I saw another conflict and
> noticed that there is one additional commit that was missing, I have
> to start over. With git, the work is easier because the first 4
> changes are cherry-picked as local commits, and it's quite easy to
> reorder or insert commits with 'git rebase'.
The FreeBSD repository is one of the best real world data sets available
to Subversion developers. I have referred to it several times while
working on the new conflict resolver planned for Subversion 1.10 and
have spent days running test merges against this repository.
The repository shows many difficult and interesting problems we would
normally only see in repositories that are locked up inside companies.
While some of the problems I have seen are due to limitations of SVN,
I believe most problems FreeBSD developers have with SVN are self-made.
FreeBSD developers in general do not really understand the tool and
don't know how to work arounds its weaknesses. The FreeBSD handbook has
a section on Subversion which is full of bad advice and half-truths.
I wish there was more communication between the FreeBSD and Subversion
projects about such issues, but such communication is virtually never
existed. (I may be wrong, but I think you are the only FreeBSD developer
posting on this list -- thank you!)
At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers.
There were many participants but *nobody* of them were FreeBSD developers :(
There was a clear lack of interest for this kind of communication.
So the tutorial didn't go as planned and no interesting conversation happened.
You can still find the tutorial here (one of your own bad merges was discussed
in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/
Re: svn vs. git
Hi, Stefan, Thanks for your feedback! Please see my response inline. On Fri, Jul 21, 2017 at 2:16 AM, Stefan Sperling wrote: > On Thu, Jul 20, 2017 at 08:01:55PM -0700, Xin LI wrote: > The FreeBSD repository is one of the best real world data sets available > to Subversion developers. I have referred to it several times while > working on the new conflict resolver planned for Subversion 1.10 and > have spent days running test merges against this repository. > The repository shows many difficult and interesting problems we would > normally only see in repositories that are locked up inside companies. > > While some of the problems I have seen are due to limitations of SVN, > I believe most problems FreeBSD developers have with SVN are self-made. > FreeBSD developers in general do not really understand the tool and > don't know how to work arounds its weaknesses. The FreeBSD handbook has > a section on Subversion which is full of bad advice and half-truths. I guess you mean this article? https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html Could you please be more specific with the bad advices? (It would be very helpful if we could have fixed these documents and/or practices, if possible; I'll take a look at the premier to get the issues raised in EuroBSDCon 2014 tutorial addressed). > I wish there was more communication between the FreeBSD and Subversion > projects about such issues, but such communication is virtually never > existed. (I may be wrong, but I think you are the only FreeBSD developer > posting on this list -- thank you!) I think there are other FreeBSD developers on this mailing list. > At EuroBSDcon 2014 I offered a special SVN tutorial for FreeBSD developers. > There were many participants but *nobody* of them were FreeBSD developers :( > There was a clear lack of interest for this kind of communication. > So the tutorial didn't go as planned and no interesting conversation happened. > You can still find the tutorial here (one of your own bad merges was discussed > in there, too, I believe): https://stsp.name/eurobsdcon2014-freebsd/ I didn't knew this tutorial before, and thanks for taking time to do the analysis and sharing. So if I understood correctly, when doing a vendor import with file renames, in addition of doing 'svn mv's in the vendor tree [quick question: is there some semi-automated way to do this?], the developer should also handle the merge conflicts differently in the development trunk, by replaying each merges with: svn revert # Restore the file to before merge state svn rm# Remove new file in preparation of actual merge svn mv # Move old file to new location svn merge --accept postpone ^/vendor/.../@ ^/vendor/.../@ Then do a 'svn propdel svn:mergeinfo' on these new files? [Do we need to do similar changes when merging to stable/?] And am I understanding correctly that the benefit of doing this is that the new files now get the same change history line from development trunk, instead of as a continue of the vendor history, and also avoided missing changes that happen in development trunk but not in vendor area (or development trunk)? Thanks in advance! Cheers,
Re: latest svn book?
On Thu, Jul 20, 2017 at 6:03 AM, Daniel Shahaf wrote: > Todd Armstrong wrote on Wed, 19 Jul 2017 19:22 +: > > There’s a 1.8 draft in the nightly build section of that page with a > 2016 copyright that I’ve been using. > > > > It’s not available in PDF form yet, though. > > Requests for a PDF version should be addressed to the book's mailing > list (svnbook-...@red-bean.com). > I tried on two occasions to subscribe to that mailing list but there seemed to be no response. Does anyone know why or have contact with the book maintainers? It's a very good book. I still refer to it frequently. Bringing it up-to-date with 1.9 and current best practices would benefit all of us. Also, some sections could be expanded. Just one example is how to deal with vendor branches. There was some recent discussion here about communication between the FreeBSD and Subversion maintainers, and some practices that could be updated by FreeBSD and/or improvements made to Subversion. The results of such discussions are exactly the sort of information that should be documented in the svn-book. I propose an additional chapter on real world scenarios and case studies, to help potential adopters and long-time users alike.
Re: latest svn book?
Nathan Hartman wrote on Fri, 21 Jul 2017 16:12 -0400: > I tried on two occasions to subscribe to that mailing list but there seemed > to be no response. Does anyone know why or have contact with the book > maintainers? I've forwarded Nathan's report to svnbook-dev@ (and verified that my email was in fact delivered to that list), so cmpilato et al should be aware of it now.
Re: latest svn book?
On Fri, Jul 21, 2017 at 4:47 PM, Daniel Shahaf wrote: > Nathan Hartman wrote on Fri, 21 Jul 2017 16:12 -0400: > > I tried on two occasions to subscribe to that mailing list but there > seemed > > to be no response. Does anyone know why or have contact with the book > > maintainers? > > I've forwarded Nathan's report to svnbook-dev@ (and verified that my email > was in fact delivered to that list), so cmpilato et al should be aware of > it now. > Thanks
Re: svn vs. git
On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman wrote: > On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn wrote: >> >> Not wanting to start a flame war, but for all svn users and admins out >> there that sometimes need to have this conversation ... I found this to be a >> very nice website: >> >> https://svnvsgit.com >> >> (I'm not affiliated with the website, just ran into it) > > > Thank you! Thank you! Thank you! > > I did recently have this conversation and this website could have helped > significantly. Sadly, it's not a balanced analysis. It's a "why all the news about Donald Trump is faked by the liberla media, according to Fox News" sort of analysis. Balancing information would include "Can Subversion or git delete dangerously or accidentally committed bulky or security sensitive content from the repository?" This is the longest requested feature of Subversion, and there remains no sign of it eve rhappening. If you've ever accidentally committed a file with customer passwords, or a bulky .iso image or core file to a working repository and seen your central repository grow by half a Gigabyte in a single automated commit, you'll know *exactly* what I mean. And even if committed to a branch, it's very difficult to clear from Subversion, and *far* simpler to clear entirely from a git repository. > There seem to be some comparisons out there that are comparing DVCSs against > ancient versions of Subversion. Probably those comparisons are old and > therefore their argument may have been valid at the time. But if those > comparisons are more recent, then there's a problem. Either the person > making the comparison is honestly unaware of progress made in Subversion's > development over the years, or they are deliberately comparing to old > versions to make Subversion look bad. Or they are actually looking at problems that are not the ones listed on that webpage. The need for constant network access to the Subversion master for making branches and changes, for example, makes a continuous integration and continuous development entirely dependent on that single component. Local testing branches cannot be stored locally with change history. > Regardless of how or why, I think the perception out there is just plain > wrong. I think Subversion is due a lot more credit than it gets. As I > mentioned in another thread (which may have prompted this one), we recently > evaluated other systems. We did not do this out of desire to migrate away > from Subversion; rather we did it in order to understand what's happening in > our industry, and as such we wanted to answer the question: will switching > to something else give us some new advantage? We gave git and others a fair > chance, and based on various technical, usability, and management criteria > we reached the conclusion that Subversion has been and still is the best > system for us. We manage all sorts of data with it, not just program code. Me, too. It has its uses, and tools like TortoiseSVN make it *much* easier to use for my Windows clients. > While I'm here, I'll comment on a couple of significant issues mentioned at > that site. > > Item #7 mentions the issue of a single monolithic repository vs numerous > smaller repositories, and the atomic whole-project commit, consistent > branches, and large-scale rafactoring made possible by it. These are > extremely important to us. We have numerous components whose history and > state must remain matched as they evolve. With the monolithic repository, > this happens by definition. Losing that by breaking things up into multiple > repositories (to avoid cloning a gigantic monolithic repo for every working > copy) would push a maintenance burden to everyone on our team, which is > unacceptable from a management perspective. And saying "git does not support this" is misleading itself. Large *binary* repositories are problem: Subversion users can, and do, check out single directories much more efficiently. > Item #11 mentions the issue of immutable history. We know from experience > that the ability to reproduce the exact bits at a point in time is crucial > to us. With Subversion, this very significant requirement is fulfilled, and If you're in the git world, then lean to use "tags'. Same in Subversion. > tremendous problems we had in our pre-Subversion days have disappeared. > Losing immutable history would be a huge step backwards for us. In my opinion, and it's one with decades of source control experience: Immutable history is not, per se, a "software" problem. It's a privilege problem. Who can and should be allowed to delete the history? This is one of the points where Subversion, described as "CVS done right", lost an important feature of CVS. > One myth that is not mentioned on that page is the famous, "But you can't > work offline!" Being able to work "offline" is supposed to be the biggest > selling point of a DVCS over a CVCS. Okay... I'm calling that a myth. First > of all, there is nothing i
