On Sat, Jul 22, 2017 at 6:06 AM, Johan Corveleyn <jcorvel_at_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.
Received on 2017-07-22 16:19:38 CEST