[cvsnt] Betr.: CVSNT to CVS
a.krey at gmx.de
Wed Apr 8 15:34:16 BST 2009
On Wed, 08 Apr 2009 13:43:22 +0000, Tony Hoyle wrote:
> No problem with enabling that... Personally I find the concept of
> transmitting whole repositories between users silly,
It comes close to the best thing since version control in general, IMHO.
That way I can basically do everything offline, even complicated merges,
and only need a connection for pushing back the results. I first considered
it overkill just as well but then the whole git repository is typically
smaller than all the 'pristine copy' files that svn puts in the sandbox.
> Take a scenario. Your company has an evs server. They let you use any
> client you like, but there is of course only one centrally, fully backed
> up and audited central server.
With git you would just as well have an 'official' repo, but the funny
thing is that every developer has a full backup. :-) What's more
important to me is that I can continue working even when the
central server is offline (like 'powered down for holidays').
> If they want another evs server then evs servers can sync between
> themselves just fine. There's no purpose in trying to use git to do
> that - in fact it'd be missing important metadata, so would be a very
> suboptimal solution.
That's the point I was tring to make: EVS can't come to a point where
it mimics a git server so that you can treat it like one in all regards.
> It also highlights the fundamental problem with git - someone can take
> your entire repository history and copy it out of the company, and you
> can't do a damned thing about it.
That is just as true for cvs and svn; a full copy (except for some
metadata) is just one 'git cvsimport' or 'git svn clone' away.
> Corporate customers are big on
> auditing and security - neither of which git can provide, by design. It
> also lacks things like locking, again because of its distributed nature.
You could avoid commits to a specific file on your official repo, and
that is all cvs/svn provide either. Local changes are possible (chmod
exists), and committing into the local repository *is* a local change.
Also the server auditing doesn't prevent further passing around of
stuff that once came into any sandbox. Foolish to restrict svn
access and then check it out with umask 022.
> It's a good solution for opensource development, but then evs is just
> not aimed at that.
It already occurred to me that your target audience is a bit different.
Still, I'm amazed at the speed with which git came into existence and
is running circles around svn (except in the gui department).
> >Just branch out (in cvsnt) one subdirectory, start working in that
> >branch, and merge back a few (not all) files. The history you
> >now have in cvsnt cannot be properly represented in git (and possibly
> >neither in svn). You can represent the state of the files in all
> >commits, but what is missing is the correct merge tracking information.
> What you describe there is basic version control. I don't see the
git versions trees, not files. Hence you can't have file-wise merge arrows,
and you can't represent them. This is a purposeful difference which affects
the way you organize projects, as you can't just keep using the cvsnt way.
> It's simple enough in SVN (although SVN's mergepoint stuff is
> pretty bizarre).
It's broken, actually: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
> evs records the merges for all such commits. If the
> client can't provide them, then.. it couldn't whether the server is evs
> or anything else, so nothing is lost, it's just a consequence of the
> choice of client.
Which means that no client will behave the same way as with its
native server? Or will there be one that actually maps all the
features of EVS in one?
> >Also, svn:externals aren't anything elsewhere, as are git
> >submodules or cvs modules. There are some possible mappings
> >between each other, but none of them are the only possible
> >way of doing things, and doing the mappings at least requires
> >some project-specific configuration.
> Those are implementation specific details. They don't actually change
> what's stored.
No, but if I have a svn repository that makes heavy use of svn:external,
and EVS doesn't support it, I'm rather unlikely to switch.
> >Did you design the storage model in a way that makes it possible
> >to actually work distributed? That is, do a branch here, and later
> >push that branch to the other server where other commits have already
> >been done?
> That's what the evs sync protocol does - it's how we handle keeping many
> servers in sync simultaneously.
But you can't commit to each one of them when they are disconnected
from each other?
> >a little modification and had it in his sandbox but wasn't allowed
> >to commit. Now he needed to find someone to grant him access, or
> >to carry around that file to a sandbox whose owner can commit. In git
> >he could just commit it locally and tell someone with commit rights
> >to the official repository to pull his change and push it to central.
> >Without even losing the commit attribution.)
> And if the official repository was evs it would work exactly the same
> way. Except the user could have still been working under svn and you
> could have used git to keep the modified file temporarily.
Ehm, nope. He could have given me the patch but then the svn/evs
commit would carry my name, not his.
> OTOH a user shouldn't be modifying files they don't have rights to
> *anyway*. I'd deal with that problem first.
The module responsibles are a bit easier to reach than the sysadm that
first has to ask someone in command whether the request is actually
valid. And possibly we actually *don't* want this guy to have write
access but still want to put in those things we checked first.
More information about the cvsnt