On Sat, Jul 22, 2017 at 6:06 AM, Johan Corveleyn <jcor...@gmail.com> wrote:
> Yeah, well, we know the lack of 'obliterate' is one of your favourite > complaints about svn. I am not bothered by it at all, and so are many other > svn users. But okay. > > You do realise git repositories get cloned, right? So once your password > file or iso gets pulled / pushed it will be very hard to obliterate ... It's > distributed VC after all, so you have a lot more repositories to worry about > than just one. Certainly I realize this. The segregation of commits to the local, working copy, and the separate publication to a potential centralized repository (such as github) is a very real workflow difference that allows an erroneous local commit with git to be cleared, even scratched, from the local repository and local history, before it gets published upstream for broader publicaton. Under the common Subversion model of "thou shalt not modify history", it can't be cleared at all except with the quite fraught procedure of a full "svnadmin dump, filter the dump, reload and rebuild a new upstream repo and pray you didn't make any dangerous mistakes". Been there, done that. I could tell stories, suffice to say that the ability to scrub history has proven useful. The accidental inclusion of sensitive data is one issue aided, though not completely solved this way due to possible copies. The preserved and immutable history of bulky and unnecessary content, that's another one. > Okay, your other criticism is lack of local commits, which was also made by > some other people in this thread, and that's certainly an area where svn > needs to improve. I was trying to raise other valid points of comparison, not merely "I don't like this about Subversion". That comparison webpage had a strong feel of the old CUPS documentation, a sense of "you should be only asking these particular questions", with a real lack of "what questions do people actually ask". That is actually one of the superior points about Subversion. The documentation is *good*, and the "Red Bean" documentation in fact answers all the Frequently Asked Questions. And tools like TortoiseSVN make it *much* simpler to use than the variety of less successful and less stable tools for graphical administration of Git. > As Branko already said, work is being done for this, as we speak. So if > you're interested and want to share your ideas about how this should work in > Subversion, hop over to dev@ and give your thoughts. There are some google > docs written by Julian Foad with design ideas, UI proposal etc, for > 'shelving' and 'checkpointing' (which may be a first step towards local > commits). Just search the dev@ archives for the last couple of weeks ... > input welcome. I can glance at it if I can find some cycles, no promises. I'm leery: much of Subversion's support that I've seen, and that I've sold Subversion migration work with myself, is that the singular repository can be used to force developers to commit their work daily, to gather some idea if they're actually working on their projects, and avoid them squirreling away their work without code review or consistency checks against the main development branch. Been there, done that with personnel keeping git branches on their personal laptops or personal VM's and being horrified with later merges or even with what I found out they were doing later. It's enormous fun when an employee says "I've already done that" but somehow has never published their code anywhere that other people can see the work. Frankly, there's already a workaround for doing local commits in common use. It's the "git-svn" toolkit. It's far from perfect, the handling of various "auto-fill" attributes, for example, is not reliable. But it's proven very useful for doing local commits for configuration management systems in testing environments, and for folks doing Subversion->Git migrations. And where I can, I try to forbid or discourage the use of the various autofill attributes because they mean that what one developer has in their working copy does not necessarily what another developer has in theirs. I even publish RPM building wrappers for git-svn, for folks in the RPM based operating system world. It's proven useful, though it can lead to exactly the "you've not committed your code to the master repo!" problems of all git projects.
