You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2001/11/28 18:40:35 UTC
hard links (was Re: Subversion != your filesystem (was mv != (cp &&
rm)))
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: 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