You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mukund <mu...@tessna.com> on 2003/05/29 12:25:08 UTC
[PATCH] SVNServerSignature feature
Hi
Attached is a patch which hides the server version displayed by
Subversion in mod_dav_svn generated pages. I have used the keyword
"SVNServerSignature" as it is similar to what Apache implements using
ServerSignature. Maybe somebody can extend it.
It is useful to us here as we don't want to publish the version of
Subversion we're running. I had discussed this with two of Subversion's
developers and one of them asked me to send it here anyway. You are
welcome to use it if you need it. It has been a few days since it was
written -- it should still work with trunk.
Mukund
Re: [PATCH] SVNServerSignature feature
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 30, 2003 at 07:44:24AM -0700, Justin Erenkrantz wrote:
> --On Friday, May 30, 2003 11:48 AM +0100 Mukund <mu...@tessna.com> wrote:
>
> >ServerTokens does not do the same thing which SVNServerSignature
> >provides. Apache's ServerSignature is closer, but people will like
> >ServerSignature to be different from SVNServerSignature.
>
> Ah, sorry. I see.
>
> Well, IMHO, I think that mod_dav_svn should just emit the standard
> ServerSignature rather than emitting its own custom signature (i.e. call
> ap_psignature). And, the version info in ServerSignature is controlled by
> ServerTokens. I don't see the particular need for Subversion to do
> anything special here.
Agreed. I'd still want to see a little "Powered by Subversion" in there,
with the link to subversion.tigris.org. But the rest of the details could
easily come from ap_psignature().
> And, if you wanted to hide the version you have of Subversion, it's always
> in the Host: header if you don't have ServerTokens. So, hiding just the
> SVN signature without using ServerTokens is just pointless. -- justin
Server: response header, actually, but yup. It's gotta be removed from
there, and SVN can't do that. Thus, you'd have to use ServerTokens anyway,
so we may as well use that (via ap_psignature).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some Defects
Posted by Philip Martin <ph...@codematters.co.uk>.
"Mark Watts" <mw...@stny.rr.com> writes:
> However, I have a new question. When a merge fails, as it did in this
> situation, it can leave the working copy in an unknown state.
Unknown? The status command should work. The merge command lists the
items it affects. Those should be enough to allow you to determine the
working copy state.
> I used 'svn revert' as the means to try and bring the working copy
> back to a known state and from what you are both saying it did so as
> far as the subversion meta-data in '.svn' directories was concerned
> AND as far as reverting modified or deleted files to the state they
> were at prior to the merge.
Not quite. If the working copy file had local changes before the
merge then running revert will undo both the merge and the local
changes.
> However, because the add was done and then unscheduled the revert didn't
> really 'undo' the merge completely. Right? What is the standard way to
> correct this situation?
There is no general way to undo a merge automatically. If there were
no local modifications prior to the merge, and if no conflicts created
during the merge, then the command
svn merge -rX:Y URL wc
could be reversed using
svn merge -rY:X URL wc
There is one slight disadvantage to this, if any of the merged files
end up without local changes then the text-base timestamps recorded in
the entries file will not identify those files as unmodifed. Until
the timestamp gets updated Subversion will fall back to a byte
comparison of file and text-base.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Some Defects
Posted by Mark Watts <mw...@stny.rr.com>.
> -----Original Message-----
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Friday, May 30, 2003 14:15
> To: dev@subversion.tigris.org
>
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > > 2. If for some reason the merge fails and you do a 'svn
> revert -R
> > > .' on the tree to put everything back, files that have
> been added as
> > > part of the merge are not deleted.
> >
> > That is how revert is intended to work.
>
> Correct.
>
> II create a new file, and 'svn add' it. Then I change my
> mind; I don't want to put it under version control after
> all. When I run 'svn revert', it removes the scheduling
> only. It would be awful if it deleted the file -- the data
> would be gone forever.
OK. I can see that and agree.
However, I have a new question. When a merge fails, as it did in this
situation, it can leave the working copy in an unknown state. I used 'svn
revert' as the means to try and bring the working copy back to a known state
and from what you are both saying it did so as far as the subversion
meta-data in '.svn' directories was concerned AND as far as reverting
modified or deleted files to the state they were at prior to the merge.
However, because the add was done and then unscheduled the revert didn't
really 'undo' the merge completely. Right? What is the standard way to
correct this situation?
-Thanks
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some Defects
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> > 2. If for some reason the merge fails and you do a 'svn revert -R
> > .' on the tree to put everything back, files that have been added
> > as part of the merge are not deleted.
>
> That is how revert is intended to work.
Correct.
II create a new file, and 'svn add' it. Then I change my mind; I
don't want to put it under version control after all. When I run 'svn
revert', it removes the scheduling only. It would be awful if it
deleted the file -- the data would be gone forever.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some Defects
Posted by Philip Martin <ph...@codematters.co.uk>.
"Mark Watts" <mw...@stny.rr.com> writes:
> 1. Doing 'svn merge --dry-run -r 89:124 file:///c:/svn/repos/trunk' results
> in the following error message
>
> svn: Working copy not locked
> svn: no write-lock in: src
>
> now if I do a regular merge it goes past this point just fine however the
> item that would have been printed had the dry run worked is:
> D src\file1.txt
I believe I fixed this a couple of days ago.
> 2. If for some reason the merge fails and you do a 'svn revert -R .' on the
> tree to put everything back, files that have been added as part of the merge
> are not deleted.
That is how revert is intended to work.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Some Defects
Posted by Mark Watts <mw...@stny.rr.com>.
Running WinXP (SP1)
Subversion 0.23
1. Doing 'svn merge --dry-run -r 89:124 file:///c:/svn/repos/trunk' results
in the following error message
svn: Working copy not locked
svn: no write-lock in: src
now if I do a regular merge it goes past this point just fine however the
item that would have been printed had the dry run worked is:
D src\file1.txt
Note also the excessive indentation of the deleted directory and filename
2. If for some reason the merge fails and you do a 'svn revert -R .' on the
tree to put everything back, files that have been added as part of the merge
are not deleted. When you attempt the merge again it fails because of an
"Obstructed update". NOTE: I think I may have seen something about this
already being reported an in the issue tracker but I could not find it when
I looked.
3. If the trunk has a new directory that has been added, in my case
'\trunk\bin', and then the 'bin' directory has had the svn:ignore property
set on it to ignore *.* in that directory, when the merge is done the 'bin'
directory is added correctly to the trunk but I also have conflict report
for the bin directory with the followin message (2 lines):
-------start of message
prop `svn:ignore': user deleted, but update sets it to '*.*
'.
-------end of message
a. note the use of '`' in `svn:ignore' instead of the single quote char
b. why is the message continued on a second line?
c. why is the conflict reported at all? The directory did not exist in
the branch and was added by the merge.
NOTE: This MAY be related to issues 1319 and 838 but I don't know enough
yet to be sure.
Sorry for reporting these if they are already known
Thanks
-Mark
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] SVNServerSignature feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, May 30, 2003 11:48 AM +0100 Mukund <mu...@tessna.com> wrote:
> ServerTokens does not do the same thing which SVNServerSignature
> provides. Apache's ServerSignature is closer, but people will like
> ServerSignature to be different from SVNServerSignature.
Ah, sorry. I see.
Well, IMHO, I think that mod_dav_svn should just emit the standard
ServerSignature rather than emitting its own custom signature (i.e. call
ap_psignature). And, the version info in ServerSignature is controlled by
ServerTokens. I don't see the particular need for Subversion to do anything
special here.
And, if you wanted to hide the version you have of Subversion, it's always in
the Host: header if you don't have ServerTokens. So, hiding just the SVN
signature without using ServerTokens is just pointless. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] SVNServerSignature feature
Posted by Mukund <mu...@tessna.com>.
On Thu, May 29, 2003 at 03:01:59PM -0700, Justin Erenkrantz wrote:
|
| <http://httpd.apache.org/docs-2.0/mod/core.html#servertokens>
|
| IMHO, it'd just be better to use ServerTokens rather than add some special
| feature to SVN. -- justin
|
Hi Justin
ServerTokens does not do the same thing which SVNServerSignature
provides. Apache's ServerSignature is closer, but people will like
ServerSignature to be different from SVNServerSignature.
If people are interested in this feature, and can vote if they
want SVNServerSignature to automatically follow ServerSignature, I will
change it and provide another patch.
Mukund
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] SVNServerSignature feature
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, May 29, 2003 1:25 PM +0100 Mukund <mu...@tessna.com> wrote:
> Attached is a patch which hides the server version displayed by
> Subversion in mod_dav_svn generated pages. I have used the keyword
> "SVNServerSignature" as it is similar to what Apache implements using
> ServerSignature. Maybe somebody can extend it.
<http://httpd.apache.org/docs-2.0/mod/core.html#servertokens>
IMHO, it'd just be better to use ServerTokens rather than add some special
feature to SVN. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org