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:a...@assembla.com] > > Sent: 11 July 2011 21:55 > > To: Bob Archer > > Cc: dev@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). > >
