You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gillespie ep...@pretzelnet.org on 2003/01/24 23:28:13 UTC
[PATCH] Stop resurrecting deleted files in ~/.subversion
Log message and patch follow. But first i have a question. This
function has a comment that says errors should be ignored.
Failing to create the default config directory and/or files
should not cause whatever operation the user actually requested
to fail. I agree with that 100%. Unfortunately, the comment is
inaccurate; this function *will* bomb if creating the files
fails. Can i fix that in this patch also? The correct behavior
for this function, IMNSHO, is never to fail.
Here is what i mean:
0 ~% mv .subversion .subversion.cur
0 ~% touch .subversion
0 ~% chmod 0 .subversion
0 ~% svn st -Nq
/u/epg/work/svn/trunk/subversion/libsvn_subr/config_file.c:354:
(apr_err=125001)
svn: Bogus filename
svn: Can't open config file /u/epg/.subversion/config
That is broken.
Current log message and patch (doesn't fix that issue yet, only
the one in the Subject):
Currently, svn has the annoying behavior of restoring files i have
deleted from the .subversion configuration directory. See how
annoying it is:
0 .subversion% svn st
? README
M servers
0 .subversion% rm README
0 .subversion% ls README
ls: README: No such file or directory
1 .subversion% svn st
? README
M servers
Grrrrr.
* subversion/libsvn_subr/config_file.c:
(svn_config_ensure): When the .subversion directory does not exist,
attempt to create it and the default files. Do not attempt to
create the default files when the directory already exists.
Index: subversion/libsvn_subr/config_file.c
===================================================================
--- subversion/libsvn_subr/config_file.c (revision 4549)
+++ subversion/libsvn_subr/config_file.c (working copy)
@@ -450,6 +450,12 @@
apr_status_t apr_err;
svn_error_t *err;
+ /* XXX: I agree with this comment, but it is not in fact followed.
+ Hopefully people agree i should fix that... */
+ /* If we get errors trying to do things below, just stop and return
+ success. There's no _need_ to init a config directory if
+ something's preventing it. */
+
/* Ensure that the user-specific config directory exists. */
SVN_ERR (svn_config__user_config_path (path, NULL, pool));
@@ -462,31 +468,22 @@
apr_err = apr_dir_make (path, APR_OS_DEFAULT, pool);
if (apr_err)
return SVN_NO_ERROR;
- }
- else if (kind != svn_node_dir)
- return SVN_NO_ERROR;
-
- /* Else, there's a configuration directory. */
-
- /* If we get errors trying to do things below, just stop and return
- success. There's no _need_ to init a config directory if
- something's preventing it. */
- /** Ensure that the `README' file exists. **/
- SVN_ERR (svn_config__user_config_path
- (path, SVN_CONFIG__USR_README_FILE, pool));
+ /** Ensure that the `README' file exists. **/
+ SVN_ERR (svn_config__user_config_path
+ (path, SVN_CONFIG__USR_README_FILE, pool));
- if (! path) /* highly unlikely, since a previous call succeeded */
- return SVN_NO_ERROR;
+ if (! path) /* highly unlikely, since a previous call succeeded */
+ return SVN_NO_ERROR;
- err = svn_io_check_path (path, kind, pool);
- if (err)
- return SVN_NO_ERROR;
+ err = svn_io_check_path (path, kind, pool);
+ if (err)
+ return SVN_NO_ERROR;
- if (kind == svn_node_none)
- {
- apr_file_t *f;
- const char *contents =
+ if (kind == svn_node_none)
+ {
+ apr_file_t *f;
+ const char *contents =
This directory holds run-time configuration information for Subversion\n
clients. The configuration files all share the same syntax, but you\n
should examine a particular file to learn what configuration\n
@@ -595,40 +592,41 @@
REGISTRY:HKCU\\Software\\Tigris.org\\Subversion\\Hairstyles\n
\n;
- apr_err = apr_file_open (f, path,
- (APR_WRITE | APR_CREATE | APR_EXCL),
- APR_OS_DEFAULT,
- pool);
-
- if (! apr_err)
- {
- apr_err = apr_file_write_full (f, contents, strlen (contents), NULL);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- writing config file `%s', path);
-
- apr_err = apr_file_close (f);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- closing config file `%s', path);
+ apr_err = apr_file_open (f, path,
+ (APR_WRITE | APR_CREATE | APR_EXCL),
+ APR_OS_DEFAULT,
+ pool);
+
+ if (! apr_err)
+ {
+ apr_err = apr_file_write_full (f, contents, strlen (contents),
+ NULL);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ writing config file `%s', path);
+
+ apr_err = apr_file_close (f);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ closing config file `%s', path);
+ }
}
- }
- /** Ensure that the `servers' file exists. **/
- SVN_ERR (svn_config__user_config_path
- (path, SVN_CONFIG__USR_SERVERS_FILE, pool));
+ /** Ensure that the `servers' file exists. **/
+ SVN_ERR (svn_config__user_config_path
+ (path, SVN_CONFIG__USR_SERVERS_FILE, pool));
- if (! path) /* highly unlikely, since a previous call succeeded */
- return SVN_NO_ERROR;
+ if (! path) /* highly unlikely, since a previous call succeeded */
+ return SVN_NO_ERROR;
- err = svn_io_check_path (path, kind, pool);
- if (err)
- return SVN_NO_ERROR;
-
- if (kind == svn_node_none)
- {
- apr_file_t *f;
- const char *contents =
+ err = svn_io_check_path (path, kind, pool);
+ if (err)
+ return SVN_NO_ERROR;
+
+ if (kind == svn_node_none)
+ {
+ apr_file_t *f;
+ const char *contents =
### This file specifies server-specific protocol parameters,\n
### including HTTP proxy information, HTTP timeout settings, and\n
### svn protocol tunnel agents (for running svn over ssh or similar\n
@@ -698,40 +696,41 @@
# No http-timeout, so just use the builtin default.\n
# No neon-debug-mask, so neon debugging is disabled.\n;
- apr_err = apr_file_open (f, path,
- (APR_WRITE | APR_CREATE | APR_EXCL),
- APR_OS_DEFAULT,
- pool);
-
- if (! apr_err)
- {
- apr_err = apr_file_write_full (f, contents, strlen (contents), NULL);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- writing config file `%s', path);
-
- apr_err = apr_file_close (f);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- closing config file `%s', path);
+ apr_err = apr_file_open (f, path,
+ (APR_WRITE | APR_CREATE | APR_EXCL),
+ APR_OS_DEFAULT,
+ pool);
+
+ if (! apr_err)
+ {
+ apr_err = apr_file_write_full (f, contents, strlen (contents),
+ NULL);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ writing config file `%s', path);
+
+ apr_err = apr_file_close (f);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ closing config file `%s', path);
+ }
}
- }
- /** Ensure that the `config' file exists. **/
- SVN_ERR (svn_config__user_config_path
- (path, SVN_CONFIG__USR_CONFIG_FILE, pool));
+ /** Ensure that the `config' file exists. **/
+ SVN_ERR (svn_config__user_config_path
+ (path, SVN_CONFIG__USR_CONFIG_FILE, pool));
- if (! path) /* highly unlikely, since a previous call succeeded */
- return SVN_NO_ERROR;
+ if (! path) /* highly unlikely, since a previous call succeeded */
+ return SVN_NO_ERROR;
- err = svn_io_check_path (path, kind, pool);
- if (err)
- return SVN_NO_ERROR;
-
- if (kind == svn_node_none)
- {
- apr_file_t *f;
- const char *contents =
+ err = svn_io_check_path (path, kind, pool);
+ if (err)
+ return SVN_NO_ERROR;
+
+ if (kind == svn_node_none)
+ {
+ apr_file_t *f;
+ const char *contents =
### This file configures various client-side behaviors.\n
###\n
### The commented-out examples below are intended to demonstrate\n
@@ -739,7 +738,7 @@
\n
### Section for authentication and authorization customizations.\n
### Set store-password to 'no' to avoid storing your subversion\n
- ### password in your working copies. It defaults to 'yes'.\n
+ ### password in your working copies. It defaults to 'yes'.\n
# [auth]\n
# store-password = no\n
\n
@@ -773,27 +772,29 @@
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#*
\n
### Set compression to 'no' to avoid compressing requests\n
- ### to a DAV-enabled Subversion server. It defaults to 'yes'.\n
+ ### to a DAV-enabled Subversion server. It defaults to 'yes'.\n
# compression = yes\n
### See http://subversion.tigris.org/issues/show_bug.cgi?id=668\n
### for what else will soon be customized in this file.\n;
-
- apr_err = apr_file_open (f, path,
- (APR_WRITE | APR_CREATE | APR_EXCL),
- APR_OS_DEFAULT,
- pool);
- if (! apr_err)
- {
- apr_err = apr_file_write_full (f, contents, strlen (contents), NULL);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- writing config file `%s', path);
-
- apr_err = apr_file_close (f);
- if (apr_err)
- return svn_error_createf (apr_err, NULL,
- closing config file `%s', path);
+ apr_err = apr_file_open (f, path,
+ (APR_WRITE | APR_CREATE | APR_EXCL),
+ APR_OS_DEFAULT,
+ pool);
+
+ if (! apr_err)
+ {
+ apr_err = apr_file_write_full (f, contents, strlen (contents),
+ NULL);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ writing config file `%s', path);
+
+ apr_err = apr_file_close (f);
+ if (apr_err)
+ return svn_error_createf (apr_err, NULL,
+ closing config file `%s', path);
+ }
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel kf...@newton.ch.collab.net.
Mix mixtim@acm.org writes:
Well, I can't speak for Eric, but as for myself, I'd be happy if
~/.subversion problems were warnings instead of hard failures. If
there is a problem with some file there then just warn the user
(unless -q is specified) and continue with the defaults.
There is no need to abort the entire command.
Yes. That's a separate bug -- which everyone agrees is a bug, and
which Eric may be patching soon, actually (see his earlier mail about
it).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Mix mi...@acm.org.
Karl Fogel wrote:
Yah, Colin's mail is my reaction too. How is Subversion supposed to
know what to do when one of those files is missing? For some people,
it's good if svn creates it. For other people, it's bad.
We could have a special flag file (or config option) whose presence
indicates that Subversion shouldn't try to do anything more in there,
but is the extra complexity worth the small annoyance it would save
some users?
Eric, aside from the It's-My-Directory-Dammit Factor, was this causing
you any other problem? Or is that problem so bad? I mean, I
understand the annoyance (believe me, have felt similarly about other
software in the past... certain window managers who shall remain
nameless...), but in this case, one user's bug is another's feature.
Well, I can't speak for Eric, but as for myself, I'd be happy if
~/.subversion problems were warnings instead of hard failures. If there
is a problem with some file there then just warn the user (unless -q is
specified) and continue with the defaults.
There is no need to abort the entire command.
Mix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by mark benedetto king mb...@boredom.org.
On Sat, Jan 25, 2003 at 05:50:52PM -0500, Eric Gillespie wrote:
minority. It shouldn't surprise me. We've been losing control
over our home directories for years now.
First they came for the .emacs, and I didn't speak up because
I was a vi user. Then they came for the .cvspass, and I didn't
speak up because I was a :ext: user...
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Justin Erenkrantz je...@apache.org.
--On Sunday, January 26, 2003 9:55 AM -0800 David Kimdon
dwhedon@debian.org wrote:
Perhaps if the templates were not included inlined in the C source
files, but instead text copies were kept under revesion control and
logic during the build would process them properly for inclusion in
the C source. That way we would have plain text copies available.
Sounds like the template code that we're using for 'svnadmin create'
could also be used for this. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by David Kimdon dw...@debian.org.
On Sun, Jan 26, 2003 at 10:42:55AM -0500, Eric Gillespie wrote:
Yes, i like that. So if i think there is a new config file that
i don't see in my .subversion dir, i can run 'svn setup' or
something to copy in any misisng files (and of course it can just
overwrite the old README). I think that addresses the concerns
about not being able to install new files.
While we are on the subject . . . I'd like to be able to easily create
new entries for /etc/subversion/ at build time. I include these files
in the Debian package but need to manually keep them up to date. (no
simple way to programatically extract the templates from
libsvn_subr/config_file.c).
Perhaps if the templates were not included inlined in the C source
files, but instead text copies were kept under revesion control and
logic during the build would process them properly for inclusion in
the C source. That way we would have plain text copies available.
(yes, if we like the idea, I will do it.)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Greg Hudson ghudson@MIT.EDU writes:
svn status option.) Subversion is not about its dotfiles and should
not have a command which is about playing with dotfiles.
Clearly you and i differ on which of these is the lesser evil :).
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Mix mi...@acm.org.
Greg Hudson wrote:
Eric Gillespie wrote:
Yes, i like that. So if i think there is a new config file that
i don't see in my .subversion dir, i can run 'svn setup' or
something to copy in any misisng files (and of course it can just
overwrite the old README). I think that addresses the concerns
about not being able to install new files.
+1
-0.5 on adding a new command for this purpose. Commands are a precious
commodity. Some other revision control systems have triple-digit
numbers of commands, and that can make for a very steep learning curve.
We have 27 commands by my count, which is much better. (I can imagine
condensing that list a bit with a lot of work: svn cleanup would go
away if we had a better wc design; svn info might be collapsed into an
svn status option.) Subversion is not about its dotfiles and should
not have a command which is about playing with dotfiles.
Sorry, forgot how specific everything this list had to be.
+1 on having some way to tell subversion to recreate the .subversion
directory/files. Default to leaving it alone if its already there.
-1 on adding a new command for this purpose. I think an option is
better. Of course, we now have to have the option letters are a
precious commodity argument but there you go.
Mix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Greg Hudson gh...@MIT.EDU.
On Sun, 2003-01-26 at 12:38, Mix wrote:
Eric Gillespie wrote:
Yes, i like that. So if i think there is a new config file that
i don't see in my .subversion dir, i can run 'svn setup' or
something to copy in any misisng files (and of course it can just
overwrite the old README). I think that addresses the concerns
about not being able to install new files.
+1
-0.5 on adding a new command for this purpose. Commands are a precious
commodity. Some other revision control systems have triple-digit
numbers of commands, and that can make for a very steep learning curve.
We have 27 commands by my count, which is much better. (I can imagine
condensing that list a bit with a lot of work: svn cleanup would go
away if we had a better wc design; svn info might be collapsed into an
svn status option.) Subversion is not about its dotfiles and should
not have a command which is about playing with dotfiles.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Mix mi...@acm.org.
Eric Gillespie wrote:
Personally I would like to see to oposite of what Karl is proposing:
a flag to restore .subversion. IMO, if .subversion is present, don't
muck with it unless the flag is present.
Yes, i like that. So if i think there is a new config file that
i don't see in my .subversion dir, i can run 'svn setup' or
something to copy in any misisng files (and of course it can just
overwrite the old README). I think that addresses the concerns
about not being able to install new files.
+1
Mix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Sander Striker striker@apache.org writes:
Personally I would like to see to oposite of what Karl is proposing:
a flag to restore .subversion. IMO, if .subversion is present, don't
muck with it unless the flag is present.
Yes, i like that. So if i think there is a new config file that
i don't see in my .subversion dir, i can run 'svn setup' or
something to copy in any misisng files (and of course it can just
overwrite the old README). I think that addresses the concerns
about not being able to install new files.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> > Eric, would you mind filing an issue for this? It sounds like
> > everyone either is for it, or anyway doesn't mind :-).
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1121
Thank you!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Eric, would you mind filing an issue for this? It sounds like
> everyone either is for it, or anyway doesn't mind :-).
http://subversion.tigris.org/issues/show_bug.cgi?id=1121
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Karl Fogel kfogel@newton.ch.collab.net writes:
Eric, would you mind filing an issue for this? It sounds like
everyone either is for it, or anyway doesn't mind :-).
http://subversion.tigris.org/issues/show_bug.cgi?id=1121
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> > Anyway, would rather see a separate tool (a script?) to create a
> > ~/.subversion area, than have it be part of Subversion's interface.
> > That is, either svn create's ~/.subversion automagically, as it does
> > currently, or else it does nothing, and we have a separate tool
> > ('svn-cfg-init' or whatever) to do it.
>
> That sounds good to me.
Eric, would you mind filing an issue for this? It sounds like
everyone either is for it, or anyway doesn't mind :-).
I don't think it much matters what language the script is written in,
since it's not people's only way to get a ~/.subversion area (I'm sure
the time-honored method of copying it from a friend will be used a
lot, too).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Mix mi...@acm.org.
Eric Gillespie wrote:
Karl Fogel kfogel@newton.ch.collab.net writes:
Anyway, would rather see a separate tool (a script?) to create a
~/.subversion area, than have it be part of Subversion's interface.
That is, either svn create's ~/.subversion automagically, as it does
currently, or else it does nothing, and we have a separate tool
('svn-cfg-init' or whatever) to do it.
That sounds good to me.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel kf...@newton.ch.collab.net.
Eric Gillespie epg@pretzelnet.org writes:
Anyway, would rather see a separate tool (a script?) to create a
~/.subversion area, than have it be part of Subversion's interface.
That is, either svn create's ~/.subversion automagically, as it does
currently, or else it does nothing, and we have a separate tool
('svn-cfg-init' or whatever) to do it.
That sounds good to me.
Eric, would you mind filing an issue for this? It sounds like
everyone either is for it, or anyway doesn't mind :-).
I don't think it much matters what language the script is written in,
since it's not people's only way to get a ~/.subversion area (I'm sure
the time-honored method of copying it from a friend will be used a
lot, too).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Karl Fogel kfogel@newton.ch.collab.net writes:
Anyway, would rather see a separate tool (a script?) to create a
~/.subversion area, than have it be part of Subversion's interface.
That is, either svn create's ~/.subversion automagically, as it does
currently, or else it does nothing, and we have a separate tool
('svn-cfg-init' or whatever) to do it.
That sounds good to me.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel kf...@newton.ch.collab.net.
Sander Striker striker@apache.org writes:
Karl Fogel kfogel@newton.ch.collab.net writes:
We could have a special flag file (or config option) whose presence
indicates that Subversion shouldn't try to do anything more in there,
but is the extra complexity worth the small annoyance it would save
some users?
Oh god, an unbreak-my-app option? Havoc Pennington has a nice
rant about the scourge of free software: papering over problems
with preferences. Unfortunately, i can't find it so i can't
include it.
Personally I would like to see to oposite of what Karl is proposing:
a flag to restore .subversion. IMO, if .subversion is present, don't
muck with it unless the flag is present.
Notice that I *wasn't* proposing it, I was describing it for the sole
purpose of saying that it wasn't worth doing. Thought my paragraph
(quoted above) made that pretty clear... Oh well. :-)
Anyway, would rather see a separate tool (a script?) to create a
~/.subversion area, than have it be part of Subversion's interface.
That is, either svn create's ~/.subversion automagically, as it does
currently, or else it does nothing, and we have a separate tool
('svn-cfg-init' or whatever) to do it.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Sander Striker st...@apache.org.
From: epg@remus.pretzelnet.org [mailto:epg@remus.pretzelnet.org]On
Behalf Of Eric Gillespie
Karl Fogel kfogel@newton.ch.collab.net writes:
We could have a special flag file (or config option) whose presence
indicates that Subversion shouldn't try to do anything more in there,
but is the extra complexity worth the small annoyance it would save
some users?
Oh god, an unbreak-my-app option? Havoc Pennington has a nice
rant about the scourge of free software: papering over problems
with preferences. Unfortunately, i can't find it so i can't
include it.
This is a problem. I don't want to see problems addressed in
conditional code only executed if the myriad unbreak-my-app
options are flipped on. Unfortunately, i seem to be in the
minority. It shouldn't surprise me. We've been losing control
over our home directories for years now.
Personally I would like to see to oposite of what Karl is proposing:
a flag to restore .subversion. IMO, if .subversion is present, don't
muck with it unless the flag is present.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Karl Fogel kfogel@newton.ch.collab.net writes:
We could have a special flag file (or config option) whose presence
indicates that Subversion shouldn't try to do anything more in there,
but is the extra complexity worth the small annoyance it would save
some users?
Oh god, an unbreak-my-app option? Havoc Pennington has a nice
rant about the scourge of free software: papering over problems
with preferences. Unfortunately, i can't find it so i can't
include it.
This is a problem. I don't want to see problems addressed in
conditional code only executed if the myriad unbreak-my-app
options are flipped on. Unfortunately, i seem to be in the
minority. It shouldn't surprise me. We've been losing control
over our home directories for years now.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel kf...@newton.ch.collab.net.
Colin Watson cjwatson@flatline.org.uk writes:
On Fri, Jan 24, 2003 at 06:28:13PM -0500, Eric Gillespie wrote:
* subversion/libsvn_subr/config_file.c:
(svn_config_ensure): When the .subversion directory does not exist,
attempt to create it and the default files. Do not attempt to
create the default files when the directory already exists.
That means that no extra files can ever be cleanly added to
~/.subversion, because existing users won't pick them up. There would
need to be some kind of versioning if this went in, I feel.
Yah, Colin's mail is my reaction too. How is Subversion supposed to
know what to do when one of those files is missing? For some people,
it's good if svn creates it. For other people, it's bad.
We could have a special flag file (or config option) whose presence
indicates that Subversion shouldn't try to do anything more in there,
but is the extra complexity worth the small annoyance it would save
some users?
Eric, aside from the It's-My-Directory-Dammit Factor, was this causing
you any other problem? Or is that problem so bad? I mean, I
understand the annoyance (believe me, have felt similarly about other
software in the past... certain window managers who shall remain
nameless...), but in this case, one user's bug is another's feature.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Colin Watson cjwatson@flatline.org.uk writes:
I should have said checked out.
Nothing special, just svn co.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Colin Watson cj...@flatline.org.uk.
On Fri, Jan 24, 2003 at 08:14:21PM -0500, Eric Gillespie wrote:
Colin Watson cjwatson@flatline.org.uk writes:
How did you manage to get ~/.subversion checked in?
Nothing special, just svn add svn ci.
I should have said checked out.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Colin Watson cjwatson@flatline.org.uk writes:
That means that no extra files can ever be cleanly added to
~/.subversion, because existing users won't pick them up. There would
need to be some kind of versioning if this went in, I feel.
Addressed in my reply to Brane.
How did you manage to get ~/.subversion checked in?
Nothing special, just svn add svn ci.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Colin Watson cj...@flatline.org.uk.
On Fri, Jan 24, 2003 at 06:28:13PM -0500, Eric Gillespie wrote:
* subversion/libsvn_subr/config_file.c:
(svn_config_ensure): When the .subversion directory does not exist,
attempt to create it and the default files. Do not attempt to
create the default files when the directory already exists.
That means that no extra files can ever be cleanly added to
~/.subversion, because existing users won't pick them up. There would
need to be some kind of versioning if this went in, I feel.
How did you manage to get ~/.subversion checked in? I tried back when I
was importing my home directory, but eventually gave up; I could never
get an update to work properly because 'svn up' created ~/.subversion
before trying to update it and so got Obstructed update. Eventually I
decided that this was probably just as well.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= brane@xbc.nu writes:
Well, tough. What are you removing that file for? Does it bother you so
much?
No, NOT tough. That's *my* directory. It isn't private svn
data. It's mine. And i don't need a fucking README in it. Some
people won't need a config file, or a servers file, or any of the
other files that may one day be there. And i don't need my svn
st output cluttered with garbage when i check the status of that
directory. And papering over the problem with an svn:ignore
property is not the answer. Subversion just needs to stop
leaving its droppings in *my* home directory.
This seems like a very, very fragile way to go. *If* it turns out that
we really need this feature -- something I'm not sure about -- then it's
be much better to test for ~/.subversion/README, just like we test for
.svn/README in the WC. That would at least give us a measure of
confidence that Subversion created the config directory, not someone else.
Nope. Subversion did *NOT* create my .subversion directory. *I*
did. When i checked out my dotfiles on this machine. And it's
none of Subversion's business who created .subversion. It's *my*
directory.
What exactly is fragile about it? Subversion should not
*require* a .subversion directory. In its absence, it can make a
reasonable effort at creating one, but no more. When i request
operation foo and it fails to create .subversion or some file
therein, it should not fail. Because i didn't ask it to leave
droppings; i asked for operation foo. If a .subversion already
exists, then Subversion has ALREADY BEEN CONFIGURED. To leave
droppings on that existing configuration is wrong.
And yes, that means you can't cleanly add new files to existing
.subversion directores. That's tough luck on Subversion's part.
My home directory is not a location for it to drop documentation
and example files. Documentation and example files have their
place.
I accept the convenience of Subversion making a reasonable effort
at setting up .subversion. Note that i did not send a patch
disabling this entirely. I simply restored control of the
directory to its rightful owner. Once more, with feeling: this
is *my* directory.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Branko Čibej br...@xbc.nu.
Eric Gillespie wrote:
Currently, svn has the annoying behavior of restoring files i have
deleted from the .subversion configuration directory. See how
annoying it is:
0 .subversion% svn st
? README
M servers
0 .subversion% rm README
0 .subversion% ls README
ls: README: No such file or directory
1 .subversion% svn st
? README
M servers
Grrrrr.
Well, tough. What are you removing that file for? Does it bother you so
much?
* subversion/libsvn_subr/config_file.c:
(svn_config_ensure): When the .subversion directory does not exist,
attempt to create it and the default files. Do not attempt to
create the default files when the directory already exists.
This seems like a very, very fragile way to go. *If* it turns out that
we really need this feature -- something I'm not sure about -- then it's
be much better to test for ~/.subversion/README, just like we test for
.svn/README in the WC. That would at least give us a measure of
confidence that Subversion created the config directory, not someone else.
--
Brane Čibej brane@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: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Eric Gillespie ep...@pretzelnet.org.
Karl Fogel kfogel@newton.ch.collab.net writes:
Separate patches for unrelated fixes are better, if you can.
Yes, that's a good rule, and i wouldn't even ask normally. But
this patch changes every line in this function except the
config-file text. One patch or the other would necessarily
depend on the other, and it seemed easier to me to include both
changes in the same diff.
--
Eric Gillespie * epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Karl Fogel kf...@newton.ch.collab.net.
Eric Gillespie epg@pretzelnet.org writes:
Log message and patch follow. But first i have a question. This
function has a comment that says errors should be ignored.
Failing to create the default config directory and/or files
should not cause whatever operation the user actually requested
to fail. I agree with that 100%. Unfortunately, the comment is
inaccurate; this function *will* bomb if creating the files
fails. Can i fix that in this patch also? The correct behavior
for this function, IMNSHO, is never to fail.
Separate patches for unrelated fixes are better, if you can.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop resurrecting deleted files in ~/.subversion
Posted by Henrik Holmboe <el...@hack.se>.
Hi list,
I would like to raise this question again. I recently tried adding
.subversion/config to a repository of my $HOME. It is currently not
possible to run svn update from another box (below called
box-b). What I did was (from my memory):
box-a$ mv .subversion .subversion.tmp
box-a$ svn mkdir .subversion
And then moved the config in there, and somehow got it commited to the
repository. Then on another box I can verify that it is supposed to
be checked out with with the next update. Which fails like this:
box-b$ svn up
svn: Obstructed update
svn: failed to add directory '.subversion': object of the same name
already exists
Then on box-a, I thought it was better to reverse things, so I issued
svn delete .subversion/config and commited it. I was not able to
delete the whole of .subversion (empty, only config in it, or fully
populated):
box-a$ svn delete --force .subversion
D .subversion
box-a$ svn ci -m'* .subversion: Removed this too...'
Deleting .subversion
svn: A problem occured; see later errors for details
svn: Commit succeeded, but other errors follow:
svn: Left locally modified or unversioned files
svn: Error bumping revisions post-commit (details follow):
svn:
And it is still marked for upgrade and therefore preventing a full
update on box-a.
box-b$ svn st -uv | grep .subversion
? * .subversion
So firstly I would like to request information on how to sanely
resolve the issue at hand. Secondly, in my opinion this should be
made possible in some way. I dont know whats the best solution, but
maybe anyone of you do.
.henrik
--
__________________________ _____________________________________
/______________________ | [Henrik Holmboe, Stockholm, Sweden ]
| _________________ /| | [Email : henrik.holmboe[at]hack.se ]
| | |_______________|_| | [Web : http://elements.hack.se ]
| |/______________________| [IRC : elements, irc.du.se (EFnet) ]
|__________________________/ [Cell : +46 (0)8 2281884 ]
[ Network Engineer OpenPGP: 0x723D4FFF ]
[ Planet X Systems, www.pxs.se "Carpe Noctem" -- H. Holmboe, 1995 ]