Paul Burba wrote:
> My memory is a bit fuzzy on this, but as I recall these ideas were
> abandoned, or at least put off, because they both try to guess the
> user's intent a bit too much. In the case of "new" (i.e.
> unobstructing unversioned) files in a directory, perhaps the user
> *really* wants these to remain unversioned. Yes, I know they could
> revert them after the fact, but they could just as easily add them
> after the fact too. I think this is a case where some group of
> people will be unhappy no matter what the behavior is(?).
Exactly. This is why the behaviour should be discussed exclusively on the
basis of real-world use-cases (as it is always done for Subversion
features), and not on the basis of what "is supposed" to be better. I cannot
find the design document for the takeover version that was eventually
committed, so I cannot see what the rationale is for either choice.
If you decide *not* to schedule-add/remove files in obstructed directory,
you obtain a working copy which very close to what would happen if you first
checkout, and then copy your directory over the working copy. In other
words, what Subersion is doing is just saving the "copy-over" pass, which is
better than nothing but really not a great deal. On the other hand, adding /
removing files in obstructed directory is *very* tedious and annyoing. It
basically requires some shell scripting to be done in a complex tree, and
for instance you simply cannot do it in an automatic fashion under Windows.
>> If this was the case, "svn checkout --force" would
>> automatically do much of the job of svn_load_dirs.pl, and thus would
>> be dramatically useful for vendor branches.
>
> Sorry, I'm not familiar with svn_load_dirs.pl so I'll have to let
> someone else speak to that.
svn_load_dirs.pl was born exactly for this specific scenario (vendor
branches). If you committed foo 1.0 to your repository and you get
foo-1.1.tar.gz, you want to commit it into the repository "as if" it was a
single patch (that brings 1.0 to 1.1). To do it manually, you need to
checkout the 1.0 version, unpack the tar.gz over it, and then add/remove all
files manually. svn_load_dirs automates this process, and also tries to
detect renamed files, do the commit, ecc.
This is why I would like "svn co --force" to behave like this. It would be a
great support for vendor branches, which is widely common use cases (and
even if it's irrelevant, let me note that CVS supports vendor branches much
better than SVN does, since for instance it takes care of this
automatically).
I'm curious about whether there are use cases in which adding/removing files
in obstructed directories is worse than doing nothing with them, because I
cannot think of them right now. I guess that, if they exist, they are in the
design document (which I cannot find). Otherwise, if this specific aspect
was never discussed before in this context, my +1 is towards
auto-schedule-add/delete in obstructed directory.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 15 18:16:43 2006