Re: excellent GIT video

I think that Subversion needs to look at SVK very closely and consider
the value in consuming some of its differences. We absolutely need a
new working copy model (and clearly that has been taken on-board from
observed discussions).

Perhaps a better working copy really should include repository clone.
We might want to narrow that definition to being a filtered set of
content by perhaps discarding content that is not relevant to the
subtree that has been checked out (just to manage volume for those
users where the total volume is far too large to clone at every
checkout).

I certainly don't like the idea of losing the ability to express
explicit copies/renames. We probably do want to support 'local
commits' to support folding a sequence of dependent changes into a
single repository commit (mixing in some of what is missing in the svn
client but which is supported currently via svnmucc).

--
Talden
On 11/2/07, John Peacock <john.peacock@havurah-software.org> wrote:
> Greg Hudson wrote:
> > A distributed version control system might work very poorly when off the
> > net, e.g. if it frequently has to go off and contact other people's
> > repostories in order to provide history information.  A centralized
> > version control system might work very well when off the net, e.g. if
> > you keep a cached copy of the whole repository.  Two very different axes
> > of functionality.
>
> Except SVK allows me to have a full mirror of the main repo, so it is
> not "distributed" in the sense you are using.  SVK really is a
> disconnected Subversion client and if Subversion grew that capability
> natively, I'd be a happy camper because it is a very nice way to work.
>
> I'm not trying to evangelize about SVK (and I've been using Subversion
> longer than I have been using SVK).  I am also one of the primary voices
> of caution against moving the Perl repo to a Git backend, so I am
> automatically biased against Git... ;-)
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org