I was going to ask about this a few weeks ago, but I guess it's already
been brought up. I'm a relatively new (but very happy) Subversion user
storing Java files.
In my experience, good design requires frequent refactoring. Here's a
frequent scenario: com/company/application/BuildingBlock.java gets moved
to com/company/generic/BuildingBlock.java . (This is particularly
important in Java, which uses a directory structure to represent
hierarchical packages.)
When figuring out how to rename files, I noticed that the svn
documentation states that MOVE=COPY+DELETE. This reduces the utility of
Subversion (if only ever-so-slightly). Consider the following two problems:
1. I realize there's a bug in the new
com/company/generic/BuildingBlock.java , but I can't revert to a
previous version, because that file has no previous version. If I were
familiar with the project, I might know that this corresponded to the
deleted com/company/application/BuildingBlock.java , but it might also
correspond to the deleted org/othercompany/division/BuilderBlok.java .
If every rename breaks versioning, then refactoring is like restarting
the repository every few revisions---at least for some files.
2. Let's say I'm 39,000 feet over the Atlantic and I refactor by moving
com/company/application/BuildingBlock.java to
com/company/generic/BuildingBlock.java . Then I realize, oops, that
BuildingBlock.java really can't be made into a generic module, so I want
to move it back to com/company/application/BuildingBlock.java . In my
experience, Subversion doesn't let me move the file back until I've
committed the first move---the copy+delete. Maybe there's a way to say,
"undo the copy and delete," but I haven't found it. It's awfully
frustrating in an airplane to be required to commit just to un-move a file.
Everything else is a dream come true. (Ignoring the outrageously poor
WebDAV support in Windows Explorer.)
Cheers,
Garret
Philipp wrote:
> Hi all,
>
> long time lurker and (if i remember correctly) first time poster.
> Just yesterday i was going through some mails from january i hadn't read
> at the time because of lack thereof. When I saw the discussion of
> MOVE=COPY+DELETE again, i remembered an idea i had a few months ago,
> which might be an interesting take on the issue. (Talking of which, i
> didn't find an issue about this and haven't seen it on the ML, so i
> assume this idea is new - my apologies in advance if this has already
> been proposed/discussed.)
>
>
> _Suppose_ we had the concept of an in-repository hard-link. (I think
> somebody brought that up before). That is, if a and b link to the same
> thing, everytime i commit to a, an update would change b aswell. (a and
> b in the wc might even be hardlinked too, if the underlying OS supports
> this - but that's a completely different issue.) [1]
>
> Now a MOVE could be represented as a LINK+DELETE, instead of COPY+DELETE
> (with the LINK having the appropriate LINKFROM parameter). This would
> still preserve the possibility of discreetly commiting each end of the
> MOVE (partial commit), while putting the resulting file in better touch
> with it's ancestry, should work rather well when merging somebody else's
> changes, giving us IMHO more robust MOVE semantics (in terms of what
> happens vs. what users expect), and fries with that.
>
> (One special case i can think of that would be needed is a LINK where
> the LINKFROM source has already been deleted. This could just point the
> LINK to the last existing revision of that file, which is IMHO also a
> sensible semantic outside the MOVE case.)
>
>
> Now i know that in-repos hard-links are a biggie (and probably evil),
> that nobody has time to implement all this, especially right now, and
> that there's also the maybe even better option of truly atomic moves.
> Which is why all i'm intenting with this mail is to put the item out for
> discussion. Maybe something worthwile will come out of it.
>
> Bye,
> Philipp
>
>
> [1] A (possible) idea on how hard-links could be implemented:
>
> Quoting Branko's example from the aforementioned thread:
>
>> I'll try to illustrate the point. Imagine you have two directories "A"
>> and "B", that are children of the root. "A" contains the files "foo" and
>> "bar", B contains "qux". I'll tag each node with its node revision
>> number:
>>
>> / (0.0.4)
>> A/ (a.0.3)
>> foo (f.0.2)
>> bar (r.0.3)
>> B/ (b.0.4)
>> qux (q.0.4)
>>
>> To understand this example, you should be aware that, within the file
>> system, directory entries are nothing but named pointers to node
>> revisions (those "a.0.3" triplets); the names are not a property of the
>> node revisions themselves.
>
>
> To link A/bar to B/baz, we would need a thing (like an inode) where both
> A/bar and B/baz can point to, which in turn would point to (r.0.3), or
> (r.0.5) after the next commit.
> Another layer of indirection. *sigh*
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 7 03:05:05 2003