You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2003/12/08 22:53:45 UTC
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
epg@tigris.org writes:
> Author: epg
> Date: Mon Dec 8 16:05:50 2003
> New Revision: 7963
>
> Modified:
> trunk/subversion/libsvn_wc/adm_files.c
> Log:
> * subversion/libsvn_wc/adm_files.c
> (init_adm): Create SVN_WC__ADM_EMPTY_FILE (empty-file) group- and
> world-readable. This was needlessly preventing copying another
> user's working copy.
>
>
> Modified: trunk/subversion/libsvn_wc/adm_files.c
> ==============================================================================
> --- trunk/subversion/libsvn_wc/adm_files.c (original)
> +++ trunk/subversion/libsvn_wc/adm_files.c Mon Dec 8 16:05:50 2003
> @@ -1071,7 +1071,9 @@
> efficient than just having one around. It doesn't take up much space
> after all. */
> SVN_ERR (svn_wc__make_adm_thing (adm_access, SVN_WC__ADM_EMPTY_FILE,
> - svn_node_file, APR_UREAD, 0, pool));
> + svn_node_file,
> + APR_UREAD | APR_GREAD | APR_WREAD,
> + 0, pool));
This means that Subversion will now add group/world read access even
when the umask of the process removes it, Subversion is no longer
respecting the process umask. Now the group/world read access is not
really a problem since the file is empty, but ignoring the umask is
wrong in principle. It would be better to create the file using the
default permissions and then use the set read-only function to remove
write access.
(Yes, the old code added owner read access without reference to the
umask, that was also wrong, but I don't suppose umasks that remove
owner read are common.)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Erik Huelsmann <e....@gmx.net>.
> How about this: drop both the empty file and the README file, and
> start using SVN_NULL_DEVICE_NAME in place of the empty file. I think
> we would have to bump SVN_WC__VERSION and have maybe_upgrade_format()
> convert old working copies to the new format. (If this caused us to
> stop supporting working copies that don't have a format file I would
> not be concerned.)
I'm all for giving this a try!
bye,
Erik.
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Eric Gillespie <ep...@pretzelnet.org> writes:
>
>
>>Subversion is really an inode hog, and i'm not sure what all it
>>buys us. A README in every admin dir? Give me a break. Lots of
>>
>>
>
>The README file is probably redundant. Originally, it was used to
>confirm that the admin directory was complete, but the format file
>performs that function now.
>
>
I'd turn this around and say that the format file is redundant, and that
the WC format should be written near the beginning of the README file
instead.
Why, you ask? Because the rest of the README contents at least serve as
an "I told you so, but you wouldn't listen!" argument for people who
insist on fiddling with the admin area themselves.
--
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: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Philip Martin <ph...@codematters.co.uk> writes:
> Eric Gillespie <ep...@pretzelnet.org> writes:
>
> > I was going for the minimal impact to address my problem.
>
> Why? Are we that near 1.0?
I needed a problem solved and, much as i'd like to, i don't have
time to argue my large objections to some of what happens in the
admin dir.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>I can confirm that reading from NUL on Windows produces instant EOF,
>>which is what we want here, yes?
>>
>>
>
>I think so. We also pass it by name on the command line when running
>an external diff.
>
>
Works with GNU diff. Let's get rid of the empty files, then.
--
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: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> I can confirm that reading from NUL on Windows produces instant EOF,
> which is what we want here, yes?
I think so. We also pass it by name on the command line when running
an external diff.
>>I think we would have to bump SVN_WC__VERSION and have maybe_upgrade_format()
>>convert old working copies to the new format.
>>
> That would involve deleting the empty files, right?
Yes.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>If the empty file erroneously gets some content then Subversion may
>well produce the wrong output.
>
>
Yes!
>How about this: drop both the empty file and the README file, and
>start using SVN_NULL_DEVICE_NAME in place of the empty file.
>
We use the empty file as a source for "svn diff" on an added,
uncommitted file. If the nul device will work the same ways, then fine.
I can confirm that reading from NUL on Windows produces instant EOF,
which is what we want here, yes?
>I think we would have to bump SVN_WC__VERSION and have maybe_upgrade_format()
>convert old working copies to the new format.
>
That would involve deleting the empty files, right?
> (If this caused us to
>stop supporting working copies that don't have a format file I would
>not be concerned.)
>
>
We don't support them any more -- a WC upgrade from formats older than 2
is no longer supported.
--
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: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Philip Martin <ph...@codematters.co.uk>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> I was going for the minimal impact to address my problem.
Why? Are we that near 1.0?
> Really, i don't think we should have empty-file to begin with.
> On UNIX we have /dev/null and on Windows they have NUL or
> whatever.
I added the empty file before we had SVN_NULL_DEVICE_NAME. I wasn't
aware that Windows had a NUL device and nobody suggested that such a
thing was available.
> Subversion is really an inode hog, and i'm not sure what all it
> buys us. A README in every admin dir? Give me a break. Lots of
The README file is probably redundant. Originally, it was used to
confirm that the admin directory was complete, but the format file
performs that function now.
> that stuff could be shared by putting it only in the top level of
> the wc (like empty-file, if we really do need it).
>
>> It would be better to create the file using the default
>> permissions and then use the set read-only function to remove
>> write access.
>
> Add a whole 'nother system call? For what? Why on earth do we
> think this file has to be read-only?
It's the way all the other files in the admin directory behave.
> I can imagine some
> responses (though not necessarily from you), and they are not
> impressive.
If the empty file erroneously gets some content then Subversion may
well produce the wrong output.
How about this: drop both the empty file and the README file, and
start using SVN_NULL_DEVICE_NAME in place of the empty file. I think
we would have to bump SVN_WC__VERSION and have maybe_upgrade_format()
convert old working copies to the new format. (If this caused us to
stop supporting working copies that don't have a format file I would
not be concerned.)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Dec 08, 2003 at 07:58:04PM -0500, Eric Gillespie wrote:
> Subversion is really an inode hog, and i'm not sure what all it
> buys us. A README in every admin dir? Give me a break. Lots of
> that stuff could be shared by putting it only in the top level of
> the wc (like empty-file, if we really do need it).
>
There is no "top level of the WC" right now.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 09 December 2003 01.58, Eric Gillespie wrote:
> Philip Martin <ph...@codematters.co.uk> writes:
> I was going for the minimal impact to address my problem.
> Really, i don't think we should have empty-file to begin with.
> On UNIX we have /dev/null and on Windows they have NUL or
> whatever.
I can conform that nul works much like /dev/null
Stuff like "bla-bla 2>nul" works too.
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 7963 - trunk/subversion/libsvn_wc
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Philip Martin <ph...@codematters.co.uk> writes:
> This means that Subversion will now add group/world read access
> even when the umask of the process removes it, Subversion is no
> longer respecting the process umask. Now the group/world read
> access is not really a problem since the file is empty, but
> ignoring the umask is wrong in principle.
I was going for the minimal impact to address my problem.
Really, i don't think we should have empty-file to begin with.
On UNIX we have /dev/null and on Windows they have NUL or
whatever.
Subversion is really an inode hog, and i'm not sure what all it
buys us. A README in every admin dir? Give me a break. Lots of
that stuff could be shared by putting it only in the top level of
the wc (like empty-file, if we really do need it).
> It would be better to create the file using the default
> permissions and then use the set read-only function to remove
> write access.
Add a whole 'nother system call? For what? Why on earth do we
think this file has to be read-only? I can imagine some
responses (though not necessarily from you), and they are not
impressive.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org