You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "B. W. Fitzpatrick" <fi...@red-bean.com> on 2001/11/28 02:23:47 UTC
Subversion != your filesystem (was mv != (cp && rm))
> Regardless of how the backend is implemented, the frontend should have an
> atomic "mv".
From the info pages for ``mv'':
...It first uses some of the same code that's used by `cp -a'
to copy the requested directories and files, then (assuming the copy
succeeded) it removes the originals. If the copy fails, then the part
that was copied to the destination partition is removed. If you were
to copy three directories from one partition to another and the copy of
the first directory succeeded, but the second didn't, the first would
be left on the destination partion and the second and third would be
left on the original partition.
So it's basically cp && rm with a failsafe mode.
So, unless ``svn mv'' commits immediately, it *is* going to be
different. I think it should be. Subversion is a revision control
system, thus it has one more dimension to it than a standard OS
filesystem: time.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Florin Iucha <fl...@iucha.net>.
On Wed, Nov 28, 2001 at 10:38:22PM +0100, Mattias Rönnblom wrote:
> "Florin Iucha" <fl...@iucha.net> writes:
>
> In the "hard links" model, A points to the node-id originally pointed
> to by B. When the name B is removed, that node is only known by
> one name; A. As far as I see, the most intuitive is that all
> names of a specific node are equal. "svn link" or "svn ln" is
> probably a bad name for this operation, as it is as confusing
> as the overloaded "ln" command in UNIX. D is just a copy;
> a new node-id with only one name: D.
Maybe the UNIX pattern is too etched in my brain.
I see the model as an object with multiple aliases (inode + directory entry).
That is well known to most people. Also Clearcase has the same concept.
I am not saying that because we did it this way for 20 years we should keep
it this way. What I am saying is don't change meaning of concepts just because
you can. Also what I'm talking about is the client interface, the user
experience... most users won't care about what the repository does with their
stuff.
Again, I apologize if I misunderstood the topic and just created noise.
Thank you for your time,
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Mattias Rönnblom <ho...@lysator.liu.se>.
"Florin Iucha" <fl...@iucha.net> writes:
> On Wed, Nov 28, 2001 at 03:55:05AM +0100, Branko �ibej wrote:
> > Once we implement "svn ln" (which means a third kind of node, a
> > "reference", will appear in the filesystem), we'll have to be careful to
> > preserve the semantics of reference nodes within a copy. But that's
> > trivial -- reference nodes will behave exactly like C pointers: a copy
> > creates a new node, but its value (the node it refers to) remains the same.
>
> What will happen if I link A to B and then
> 1. cp B C && rm B
> 2. mv B C
>
> You can argue that in both cases A will link to C but, then what happens
> when
If you argue that A will link to C in both cases, you are suggesting
symbolic links. If you say that it's only in the second case
A would refer to the same node-id as C, you have a something
close to what was behind my original use case in the beginning
of this thread, which is more like hard links in a UNIX filesystem.
> cp B C && change C && cp B D && change D && rm B && commit
> where does A point to now?
>
In the "hard links" model, A points to the node-id originally pointed
to by B. When the name B is removed, that node is only known by
one name; A. As far as I see, the most intuitive is that all
names of a specific node are equal. "svn link" or "svn ln" is
probably a bad name for this operation, as it is as confusing
as the overloaded "ln" command in UNIX. D is just a copy;
a new node-id with only one name: D.
Kind regards,
Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Branko Čibej <br...@xbc.nu>.
Florin Iucha wrote:
>On Wed, Nov 28, 2001 at 06:55:24PM +0100, Branko �ibej wrote:
>
>>>What will happen if I link A to B and then
>>> 1. cp B C && rm B
>>> 2. mv B C
>>>
>>Don't know. :-)
>>The design for "svn ln" is far from complete. It hasn't even been
>>started yet, AFAIK.
>>
>
>svn ln B A will link A to the "current" B or to the B that was at the
>moment of the link?
>
Again, I don't know. These are all questions that must be answered in
the "svn ln" spec, but, as there is no such spec at the moment, there
are no answers. Your guess is as good as mine.
(Yes, it would be nice to have link tracking; and, as I said, it can be
done, up to a point. But it's not easy. Personally I'd prefer to keep
things simple: if you change a link's target, but don't change the link,
you get what you asked for.)
>>>You can argue that in both cases A will link to C
>>>
>>Possibly.
>>
>>>but, then what happens
>>>when
>>> cp B C && change C && cp B D && change D && rm B && commit
>>>where does A point to now?
>>>
>>This is not a move. A would be a dangling reference in this case.
>>
>
>Why would it be a special case when I do only one copy?
>
Because, by definition, "mv" is an *atomic* "cp & rm". Except that, in
Subversion, we can't guarantee that the cp and rm will happen in the
same commit.
Look: What you're asking is what happens to a symlink when you remove
its target. Obviously, that depends on whether you have some kind of
link tracking or not. If you don't, you get a dangling symlink. If you
do, then it all depends on how you deal with multiple copies.
(There are many ways to do that, but I don't propose go into that now.
Besides being off topic for this list, it would take too long ...)
> And if _single_
>cp followed by rm is special why not call it, let's say "mv", to show
>it's importance ? 8^)
>
See above. In general, we won't see the cp and rm happening at the same
time.
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Florin Iucha <fl...@iucha.net>.
On Wed, Nov 28, 2001 at 06:55:24PM +0100, Branko Èibej wrote:
> >What will happen if I link A to B and then
> > 1. cp B C && rm B
> > 2. mv B C
> >
> Don't know. :-)
> The design for "svn ln" is far from complete. It hasn't even been
> started yet, AFAIK.
svn ln B A will link A to the "current" B or to the B that was at the
moment of the link?
>
> >You can argue that in both cases A will link to C
> >
> Possibly.
>
> > but, then what happens
> >when
> > cp B C && change C && cp B D && change D && rm B && commit
> >where does A point to now?
> >
> This is not a move. A would be a dangling reference in this case.
Why would it be a special case when I do only one copy? And if _single_
cp followed by rm is special why not call it, let's say "mv", to show
it's importance ? 8^)
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Re: hard links (was Re: Subversion != your filesystem (was mv != (cp && rm)))
Posted by "Chris D. Sloan" <cd...@cs.hmc.edu>.
Just for the sake of curiosity, I decided to test the closest
equivalent in CVS and see what they did. I made a repository with two
modules, moda and modb. The modb module contains a file called
"foo". Then I did the following:
cd /tmp
cvs checkout moda
cd /tmp/moda/1
cvs checkout modb
cd modb
echo 1 >> foo
cd /tmp/moda/2
cvs checkout modb
cd modb
echo 2 >> foo
cd /tmp/moda
cvs commit
At this point I was asked for a commit message for moda/1/modb/foo and
moda/1/modb/foo. I entered them and the commit went through. I
looked at the file's log. It contained the original contents (rev
1.1), the original with 1 appended (rev 1.2), and the original with 2
appended (rev 1.3). In other words, the commits in the first
directory were saved as a revision, but were otherwise ignored (didn't
cause a merge).
At least it didn't lose any information, but it did sort of hide one
of the sets of changes. If I was going to suggest a proper solution,
I come up with these two ideas: 1. You could force the user to
resolve it by breaking it into two commits (and an update/merge). 2.
There could be a command to merge both versions to resolve the
conflict. That would be neat, but it seems like extra complication.
Chris
On Wed, Nov 28, 2001 at 01:40:35PM -0500, Greg Hudson wrote:
> On Wed, 2001-11-28 at 13:20, Karl Fogel wrote:
> > We don't have any plans for hard-link support in the filesystem, as
> > far as I know, actually. It's dangerous in Subversion for the same
> > reasons its dangerous in a regular filesystem -- we need to prevent
> > cycles.
>
> We can probably prevent cycles. But supporting hard links raises some
> big cans of worms, because we have to map our semantics onto a working
> directory somehow. How do we represent hard-linked files in the working
> directory? Copies? Hard links? Symbolic links? Hard links won't work
> for directories (or in AFS, if the two linked files are in different
> directories), and neither hard links nor symbolic links will work on
> non-Unix platforms. If we represent them as copies, we run into a whole
> bunch of commit-time error cases, like what happens if a user changes
> both copies and then tries to commit (or changes both copies and then
> commits one copy, and we have to try to propagate the change back to the
> other copy in the working dir).
>
> I can see some use cases for hard links (example: if apr, apache, and
> subversion all lived in the same repository, apr could exist inside both
> the apache and subversion source directories and never get out of sync
> with the master copy), but I think it's just too complicated on balance.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Chris Sloan
cds@cs.hmc.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: hard links (was Re: Subversion != your filesystem (was mv != (cp &&rm)))
Posted by Bill Tutt <ra...@lyra.org>.
Actually, the use case you site is also one of the use cases folks who
support client views site btw.
Bill
--
Bunnies aren't just cute like everybody supposes.
They got their hoppy legs and twitchy little noses.
And what's with all the carrots,
What do they need such good eyesight for anyway?
From: Greg Hudson [mailto:ghudson@MIT.EDU]
On Wed, 2001-11-28 at 13:20, Karl Fogel wrote:
> We don't have any plans for hard-link support in the filesystem, as
> far as I know, actually. It's dangerous in Subversion for the same
> reasons its dangerous in a regular filesystem -- we need to prevent
> cycles.
We can probably prevent cycles. But supporting hard links raises some
big cans of worms, because we have to map our semantics onto a working
directory somehow. How do we represent hard-linked files in the working
directory? Copies? Hard links? Symbolic links? Hard links won't work
for directories (or in AFS, if the two linked files are in different
directories), and neither hard links nor symbolic links will work on
non-Unix platforms. If we represent them as copies, we run into a whole
bunch of commit-time error cases, like what happens if a user changes
both copies and then tries to commit (or changes both copies and then
commits one copy, and we have to try to propagate the change back to the
other copy in the working dir).
I can see some use cases for hard links (example: if apr, apache, and
subversion all lived in the same repository, apr could exist inside both
the apache and subversion source directories and never get out of sync
with the master copy), but I think it's just too complicated on balance.
---------------------------------------------------------------------
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
hard links (was Re: Subversion != your filesystem (was mv != (cp &&
rm)))
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2001-11-28 at 13:20, Karl Fogel wrote:
> We don't have any plans for hard-link support in the filesystem, as
> far as I know, actually. It's dangerous in Subversion for the same
> reasons its dangerous in a regular filesystem -- we need to prevent
> cycles.
We can probably prevent cycles. But supporting hard links raises some
big cans of worms, because we have to map our semantics onto a working
directory somehow. How do we represent hard-linked files in the working
directory? Copies? Hard links? Symbolic links? Hard links won't work
for directories (or in AFS, if the two linked files are in different
directories), and neither hard links nor symbolic links will work on
non-Unix platforms. If we represent them as copies, we run into a whole
bunch of commit-time error cases, like what happens if a user changes
both copies and then tries to commit (or changes both copies and then
commits one copy, and we have to try to propagate the change back to the
other copy in the working dir).
I can see some use cases for hard links (example: if apr, apache, and
subversion all lived in the same repository, apr could exist inside both
the apache and subversion source directories and never get out of sync
with the master copy), but I think it's just too complicated on balance.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Heh heh. Who said they were hard links? I used the word "reference",
> because every time somebody says "symlink" someone else will ask if
> that's the same as a Windows shortcut. I also mentioned C pointers,
> which do behave like symlinks -- they can point to something that's
> not there any more. :-)
Oh! Yeah, symlinks are planned, but no work has been done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Branko �ibej <br...@xbc.nu> writes:
>
>>Don't know. :-)
>>The design for "svn ln" is far from complete. It hasn't even been
>>started yet, AFAIK.
>>
>
>We don't have any plans for hard-link support in the filesystem, as
>far as I know, actually. It's dangerous in Subversion for the same
>reasons its dangerous in a regular filesystem -- we need to prevent
>cycles.
>
>Of course, it *could* be done. There are just no plans now, since the
>easiest (though not the only) way to prevent cycles is to simply avoid
>operations that make them possible. :-)
>
Heh heh. Who said they were hard links? I used the word "reference",
because every time somebody says "symlink" someone else will ask if
that's the same as a Windows shortcut. I also mentioned C pointers,
which do behave like symlinks -- they can point to something that's not
there any more. :-)
>-K
>
>
>>>You can argue that in both cases A will link to C
>>>
>>Possibly.
>>
>>>but, then what happens
>>>when cp B C && change C && cp B D && change D && rm B && commit
>>>where does A point to now?
>>>
>>This is not a move. A would be a dangling reference in this case.
>>
>>
>>--
>>Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Don't know. :-)
> The design for "svn ln" is far from complete. It hasn't even been
> started yet, AFAIK.
We don't have any plans for hard-link support in the filesystem, as
far as I know, actually. It's dangerous in Subversion for the same
reasons its dangerous in a regular filesystem -- we need to prevent
cycles.
Of course, it *could* be done. There are just no plans now, since the
easiest (though not the only) way to prevent cycles is to simply avoid
operations that make them possible. :-)
-K
> >You can argue that in both cases A will link to C
> >
> Possibly.
>
> > but, then what happens
> > when cp B C && change C && cp B D && change D && rm B && commit
> >where does A point to now?
> >
> This is not a move. A would be a dangling reference in this case.
>
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Branko Čibej <br...@xbc.nu>.
Florin Iucha wrote:
>On Wed, Nov 28, 2001 at 03:55:05AM +0100, Branko �ibej wrote:
>
>>Once we implement "svn ln" (which means a third kind of node, a
>>"reference", will appear in the filesystem), we'll have to be careful to
>>preserve the semantics of reference nodes within a copy. But that's
>>trivial -- reference nodes will behave exactly like C pointers: a copy
>>creates a new node, but its value (the node it refers to) remains the same.
>>
>
>What will happen if I link A to B and then
> 1. cp B C && rm B
> 2. mv B C
>
Don't know. :-)
The design for "svn ln" is far from complete. It hasn't even been
started yet, AFAIK.
>You can argue that in both cases A will link to C
>
Possibly.
> but, then what happens
>when
> cp B C && change C && cp B D && change D && rm B && commit
>where does A point to now?
>
This is not a move. A would be a dangling reference in this case.
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Florin Iucha <fl...@iucha.net>.
On Wed, Nov 28, 2001 at 03:55:05AM +0100, Branko Èibej wrote:
> Once we implement "svn ln" (which means a third kind of node, a
> "reference", will appear in the filesystem), we'll have to be careful to
> preserve the semantics of reference nodes within a copy. But that's
> trivial -- reference nodes will behave exactly like C pointers: a copy
> creates a new node, but its value (the node it refers to) remains the same.
What will happen if I link A to B and then
1. cp B C && rm B
2. mv B C
You can argue that in both cases A will link to C but, then what happens
when
cp B C && change C && cp B D && change D && rm B && commit
where does A point to now?
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Branko Čibej <br...@xbc.nu>.
B. W. Fitzpatrick wrote:
>>Regardless of how the backend is implemented, the frontend should have an
>>atomic "mv".
>>
>
>>From the info pages for ``mv'':
>
> ...It first uses some of the same code that's used by `cp -a'
> to copy the requested directories and files, then (assuming the copy
> succeeded) it removes the originals. If the copy fails, then the part
> that was copied to the destination partition is removed. If you were
> to copy three directories from one partition to another and the copy of
> the first directory succeeded, but the second didn't, the first would
> be left on the destination partion and the second and third would be
> left on the original partition.
>
>So it's basically cp && rm with a failsafe mode.
>
>So, unless ``svn mv'' commits immediately, it *is* going to be
>different. I think it should be. Subversion is a revision control
>system, thus it has one more dimension to it than a standard OS
>filesystem: time.
>
Having written a filesystem before, I can both agree and not agree with
this. Yes, the semantics of "mv" is the same as for atomic "cp & rm",
*if* you operate on directory entries, not i-nodes. Which is not what
happens in the svn filesystem.
However, this distinction is mostly academic, because svn's fs nodes are
not i-nodes -- they remember their history. In the end, the effect is
the same. The only difference is an extra indirection deep within the
svn_fs DAG, but that's not visible outside the filesystem.
Once we implement "svn ln" (which means a third kind of node, a
"reference", will appear in the filesystem), we'll have to be careful to
preserve the semantics of reference nodes within a copy. But that's
trivial -- reference nodes will behave exactly like C pointers: a copy
creates a new node, but its value (the node it refers to) remains the same.
P.S.: Propagating changes to the target back to the reference will be
interesting, to say the least. But it's doable. :-)
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Branko Čibej <br...@xbc.nu>.
Mattias R�nnblom wrote:
>"B. W. Fitzpatrick" <fi...@red-bean.com> writes:
>
>>>Regardless of how the backend is implemented, the frontend should have an
>>>atomic "mv".
>>>
>>>>From the info pages for ``mv'':
>>
>> ...It first uses some of the same code that's used by `cp -a'
>> to copy the requested directories and files, then (assuming the copy
>> succeeded) it removes the originals. If the copy fails, then the part
>> that was copied to the destination partition is removed. If you were
>> to copy three directories from one partition to another and the copy of
>> the first directory succeeded, but the second didn't, the first would
>> be left on the destination partion and the second and third would be
>> left on the original partition.
>>
>>So it's basically cp && rm with a failsafe mode.
>>
>
>That part of the info page only applies to moving _between filesystems_.
>In Subversion, that would correspond to moving between reprositories.
>And in that special case, you could argue that mv == cp && rm. I
>would rather forbid that operation.
>
Copies (and moves, and links) between repositories would actually be
very useful.
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion != your filesystem (was mv != (cp && rm))
Posted by Mattias Rönnblom <ho...@lysator.liu.se>.
"B. W. Fitzpatrick" <fi...@red-bean.com> writes:
> > Regardless of how the backend is implemented, the frontend should have an
> > atomic "mv".
>
> >From the info pages for ``mv'':
>
> ...It first uses some of the same code that's used by `cp -a'
> to copy the requested directories and files, then (assuming the copy
> succeeded) it removes the originals. If the copy fails, then the part
> that was copied to the destination partition is removed. If you were
> to copy three directories from one partition to another and the copy of
> the first directory succeeded, but the second didn't, the first would
> be left on the destination partion and the second and third would be
> left on the original partition.
>
> So it's basically cp && rm with a failsafe mode.
>
That part of the info page only applies to moving _between filesystems_.
In Subversion, that would correspond to moving between reprositories.
And in that special case, you could argue that mv == cp && rm. I
would rather forbid that operation.
Kind regards,
Mattias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org