Hi Brian, long time no see.
Brian Behlendorf wrote:
> But I have not heard of it being the sole reason why one of our
> customers or prospects decided against the move from CVS to SVN, nor
> from any other SCM tool. That's why CollabNet's not focused on it at
> the moment, and instead on things like merge tracking and overall
> performance & quality.
Yes. To be clear, this is not necessarily a show stopper for FreeBSD.
At the moment I'm gathering requirements that need to be considered in
migrating to any new VCS, and looking at how Subversion (in my case,
others are looking at other VCSs) might address these requirements.
FWIW, you can see the current list at:
http://wikitest.freebsd.org/VersionControl
Oh, and I hope that this isn't coming across as a demand that this
feature be implemented. I know it's been requested before (hence the
issue tracker reference), but all of the use cases that I've seen have
referred to inadvertently committing large files. There's not been a
reference to inadvertently committing files which might get you in legal
trouble.
> It does have a sort of stuffing-the-genie-back-in-the-bottle feel to it.
> Commits usually trigger emails, and you can't recall those emails.
> Backups kept by a mirror will have that content.
All true. And I think the thing to focus on here is 'best effort'.
When this happened in the past to the FreeBSD project the lawyers were
happy that we'd made best efforts to remove the offending code, even if
we couldn't guarantee that it had been completely removed.
> Nik, I don't mean to discount your desire for this feature, but it might
> be useful to ask whether there are ways to mitigate the need for it.
Indeed. The dump/load cycle is one that I need to investigate more, but
my previous experiences of that cycle show it taking much longer than
we'd probably like.
I can envisage a solution that involves making regular hot copies of the
repo (say, every hour), and should a problem occur, revert back to the
previous hour's backup, and replay all the commits except the offending
one since then.
Of course, that trades disk space for time, and I don't know yet how
large the FreeBSD repo would end up. Perhaps large enough that only a
24 hour backup schedule is appropriate.
I also don't know what happens to svnsync'd copies of repos when you do
this. That's something else for me to play with.
> One thing we suggest to customers who note this and want the same thing
> is to encourage them to use lots of small individual repositories based
> on modules/projects/whatever rather than one single big one. That way,
> needing to do a dump/svnfilter/load cycle can be much shorter, and you
> don't need to take the repo down for every other team,
I don't think that's really a starter for us. One of the potential
benefits is going to be bringing everything back under one repo, and in
particular, putting all the FreeBSD long term development branches,
which currently reside in a Perforce repo, back in to the same repo as
holds the HEAD, so that merges from the development branches can retain
change history.
> and svn:externals helps make it mostly seamless for the average end user.
> The downside is
> a lack of transactional consistancy for changes that span repositories,
> but such changes suggest a lack of proper modularity anyways. It
> doesn't answer the what-about-mirrors question either.
Yes -- I think mirrors are going to mean that svn:externals are a
non-starter for FreeBSD, at least until there's support for 'relative'
externals.
> It's also not clear that the story
> would be any different for any other VC system, except those whose
> repository data model looks like CVS's - a model that prevents
> transactions, versioning of directories, efficient tagging, etc etc.
Also true -- this requirement only surfaced during a face to face
discussion at the weekend, and I don't believe the Mercurial/Hg and Git
proponents have had a chance to respond to it yet.
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 22:40:29 2006