On Tue, Jan 8, 2013 at 10:35 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 08.01.2013 10:05, Bert Huijben wrote:
>> I don’t think we can keep the moved-to tracking working between
>> multiple dbs, but I don't think we can just break that you can ‘svn
>> mv’ data between working copies.
>>
>> Maybe it should still work as add+delete in that case, but beaking
>> scenarios is for 2.0, not for 1.8.
>>
>>
>> We shouldn’t break user scenarios... especially if the only reason is
>> to keep things easy, to release something fast.
>
> We should break user scenarios if we do it for the right reasons.
Agreed.
> We
> already did that once, in 1.7 -- disjoint working copies are a thing of
> the past.
Huh? Why so? What has changed to make this something of the past?
Suppose I'm an Apache committer working on multiple projects, so I
have checked out (under C:\dev):
- cocoon
- ivy
- commons
- lucy
- hadoop
- ...
(all as disjoint working copies, the sparse working copy feature
is/was a bit too obscure for me, so I didn't know about that. I just
checked out one after the other the things I need).
Then it seems some utility code in lucy should be generalized, and
become part of commons. I'd like to move that code from lucy to
commons, while preserving history. That's a normal use case, is it
not? Doesn't matter if it's a old WC or a WC-NG, right?
> And even earlier we completely changed the .svn/entries
> format, which broke any number of automated environments.
That's something completely different ... scripts that are making use
of private internals of the svn metadata system. I have no problem in
breaking that.
> I have nothing against people doing copy + delete between different
> working copies. But they shouldn't be doing "svn move" as long as we
> have one database per working copy.
>
> (having one db for /all/ working copies would be a different
> proposition, since we then could do rename tracking properly. But that's
> not going to happen anytime soon -- if ever).
>
> I'll point out that the case where you don't have a common root dir
> checked out but still want to perform a move is easily solved by
> in-repository moves. Does it require a change in habits? Sure; but so
> did 1.7 require that a gazillion scripts stop looking at .svn/entries.
in-repos moves are useless if you want to do some automated
refactoring (done by your IDE) at the same time.
>> In those cases we should delay the feature to do things properly.
>
> Which appears to be never, right? Because someone will always find a
> weird edge-case that "worked in 1.2 but doesn't in 1.10" which will be
> argument for delaying progress again. It's the same Neon vs. Serf story
> all over again. And I have to remind you that if we'd thought in these
> terms back in 2004, we'd still not have a 1.0 release.
>
> You're basically proposing we remove cllient-side rename tracking and
> all its short- and long-term benefits because some people use Subversion
> (IMO) strange ways. Something's wrong with that picture.
I agree that we shouldn't postpone good things forever. But we should
definitely think this particular use case through, and decide what to
do with it. I don't agree that this is a total edge case and shouldn't
be supported any more.
Does anyone have any idea how hard it would be to keep the 1.8 move
(with movedto tracking) working accross disjoint working copies?
If that's too costly, what about the compromise: we keep the
disjoint-move working like it works in 1.7, but don't do movedto
tracking for it? Is that feasible? What do we lose then?
--
Johan
Received on 2013-01-08 11:24:58 CET