Paul Burba wrote:
> I thought you were referring to Alan's proposal:
>
> Alan Barrett wrote:
> > Mark Phippard wrote:
> > > Files that do not exist locally but do in the repository would
> > > be added locally and show as unmodified.
> >
> > I don't want that. I want the file to show as deleted locally ("!" in
> > output from "svn status"). Later, I can choose whether to add the file
> > locally (svn revert filename) or delete the file in the repository (svn
> > delete filename ; svn commit filename).
I was.
> If so, that is not what we're proposing. We just want checkout to
> tolerate existing files/directories, as described here in the last post on
> this topic before "take 2":
>
> Greg Hudson wrote:
> > > > I think checkout should tolerate existing directories by default.
>
> That's really it in a nutshell. Does that clear things up at all?
Sort of, yes.
I think your proposal is very fine indeed, let me just clarify that point.
But I'd like to bend things a bit differently anyway. Mainly because
I also use Subversion for incremental backups, but also because I
think it would be "cleaner".
I'll elaborate on the backup thingy, you may skip this if you find it boring.
We currently do this:
* Create a snapshot of the volume to be backed-up
* Checkout HEAD of backup repository into a new folder
* Copy files from snapshot on top of checkout
* Remove WC files from checkout that doesn't exist in snapshot anymore
* Commit
We currently duplicate a lot of code that Subversion also has, for
example to detect whether a file has changed into a directory since
the last backup, and it's also quite inefficient because we do a lot
of copying around and we have to delete WC files from 'svn co' that
doesn't exist in the real filesystem anymore.
Therefore I'd like to see a new subcommand, which would convert local
files into a working copy. That's exactly the same functionality that
Alan proposes: checkout BASE files and create .svn folders, but change
nothing else. Just for laughs, let's call this 'svn integrate'.
Then we could drop all of our backup code and just do:
* Create a snapshot of the volume to be backed-up
* 'svn integrate' to convert that to a working copy
* Commit
Assuming the new 'integrate' command, what you want *could* then be
achieved by 'svn integrate' and then 'svn up'. Correct?
I also happen to think that 'svn integrate' and 'svn up' is a much
"cleaner" approach for what you guys want to do. By "cleaner", I mean
that:
Checkout is designed for "checking something fresh out of the
repository", not "converting local files to a working copy".
When I think about modifying checkout the way you propose, I think
about how it would look in documentation. And I cannot think of a way
to explain the checkout behaviour you propose in a concise and clear
manner to users, while the 'integrate' feature seems a no-brainer to
me.
I'm in _no_ way hellbent on seeing things progress the way I'd like,
but I hope I can explain why I think it would be both prettier and
more useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 18 15:31:51 2006