If it's as simple as you say then why hasn't it been implemented yet?
Bolstridge, Andrew wrote on Tue, Jul 12, 2011 at 09:25:36 +0000:
>
>
> > -----Original Message-----
> > From: Andy Singleton [mailto:andy_at_assembla.com]
> > Sent: 11 July 2011 21:55
> > To: Bob Archer
> > Cc: dev_at_subversion.apache.org
> > Subject: Re: It's time to fix Subversion Merge
> >
> > If you want offline commit and private repositories, you can use git or
> > mercurial. We use both of them at Assembla. Subversion with those features
> > would not add much because it would look like a variant of mercurial. It
> > would lose one big advantage of subversion, which is simplicity for the user. It
> > would load the client up with new commands and mental models to move
> > changes between the client repository and the server repository, and
> > maintain local repositories.
> >
>
> You can still have simplicity while adding offline commits.
>
> With the new WC db, it's conceivable that a "--local" option could be added to svn commit that would not send the changeset to the server, but would store it in the WC, temporarily. When the user then performed a normal commit, the client could replay each local commit to the server in turn. The user gets the ability to commit when not connected to the network, can also commit code they might want to revert later, the overall subversion system doesn't get changed very much at all, and the server remains unchanged.
>
> If there are updates pending, the operation performs as it does today, alerting the user to merge if necessary, but otherwise treating all the local commits as if they were just in-progress modifications.
> For viewing history, the client needs to show the local revisions, suitably marked.
> If the user has committed several changes to a file, another commit option could be added that discards all but the last change.
> Tools such as Tortoise could 'automatically' switch to offline working if it failed to detect a network connection.
>
> Svn wouldn't get the full features of a DVCS like offline history, but then we don't want to store a local copy of the entire repository! (that said, it would be complicated, but possible, to download a cache of the last x revisions once the WC gets the ability to store local commits to provide local diffs - though I'm not sure that would be enough of an advantage to warrant the cost of implementing).
>
>
Received on 2011-07-12 12:26:33 CEST