[go: up one dir, main page]

|
|
Log in / Subscribe / Register

On what SVN can do that DVCSes can't

On what SVN can do that DVCSes can't

Posted Apr 7, 2010 3:40 UTC (Wed) by dlang (guest, #313)
In reply to: On what SVN can do that DVCSes can't by iabervon
Parent article: On projects and their goals

part of this depends on if you are looking for ways to make things work, or looking for ways that they won't work.

there were two cases mentioned as "git can't do this" that I see as reasonably easy to deal with

for your #2 (secret key) you could do a publicly accessible repository without the key, then a private repository that uses the subproject feature to refer to specific states in the public tree and also has the key in it.

I'm not finding it, but someone mentioned circuits changing and the effort to re-route the circuit board when schematic changes were made. This could be a similar thing, one project where multiple people can change the schematic, but then someone (project lead, whoever) decides that this version of the schematic is likely enough to be useful to have someone spend the day routing the board. that version of the schematic would be checked in as a subproject to the repository that contains the board routing.

or you could just only do the routing work when assigned to do so, rather than after any change.

an engineer's workstation with a TB of space could probably handle the cad files without much trouble. but is that really what the person cares about? In reality you don't have an engineer who cares about every detail of every part on the car. You have the engineers working on the axle who care about all the details of that, but the engineer working on the car as a whole is going to select axle version X and use it (ore more likely, axle model X, with specific external attachments, and variations of that model are invisible to that engineer)

This sounds like another perfect case for subprojects.

your final case (propriatary formats that can't be diffed) is a case where any VCS can do no better than storing copies of each one, but it may not be appropriate for these files to be in the VCS in the first place. Just like datbases have the concept of large objects where the database contains how to get to the object, not a copy of the object itself, the VCS may be better off storing such things elsewhere and just keeping a link to it. Git doesn't do this today, but it's been discussed, just nobody has wanted the feature badly enough to code it (or pay someone else to do so)


to post comments

On what SVN can do that DVCSes can't

Posted Apr 10, 2010 13:17 UTC (Sat) by jpnp (guest, #63341) [Link] (1 responses)

> (propriatary formats that can't be diffed) is a case where any VCS can do no better than storing copies of each one, but it may not be appropriate for these files to be in the VCS in the first place. Just like datbases have the concept of large objects where the database contains how to get to the object, not a copy of the object itself

Many binary formats can be usefully diffed using a binary diff algorithm with large savings in storage space over separate files. SVN has done this from the start in its storage system (built on xdelta IIRC). The point with binary files is that the diffs have no semantic meaning and are not useful for merging.

While some DB systems do offer the ability to store BLOBs externally, all that I can think of also allow BLOBs to be kept within the DBMS, and this is widely used too as there are management/tooling advantages to one cohesive system.

Just because git and other DVCSs have been a phenomenal success for the OSS project use-case, and many developers are keen to leave SVN behind, doesn't mean that there isn't a place for the technology. Just because git could be made to do it, SVN isn't the better fit for some use cases.

In my professional job I have just moved a development project from SVN to mercurial. Most developers where sceptical as they only have experience of CVS & SVN, but I think it'll be worth it. However, I also have projects which are storing scientific data in a VCS, that's just as valid a use for version control (we no longer call them Source Code Control Systems, do we), and I would not consider moving that away from SVN.

On what SVN can do that DVCSes can't

Posted Apr 12, 2010 1:09 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

One thing to consider is that it is better all around to use one tool than having each one be up to snuff with several.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds