You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rick Varney <ri...@sbcglobal.net> on 2011/02/22 06:54:12 UTC
A fix for issue 3471
Hello,
I am introducing Subversion into our development environment. We are using a
lock-modify-unlock stategy for all of our files. I do not claim this is the
best or most efficient way to use Subversion, but it best fits the mindset of
the developers at my particular site. We have installsed Subversion 1.6.6.
We ran into the bug documented as issue 3471: "svn up touches file w/ lock &
svn:keywords property"
http://subversion.tigris.org/issues/show_bug.cgi?id=3471
This is an annoyance for us, as we are using make to do our builds.
I am new to the subversion community, though I have had my eye on it for a long
time. Here are my questions:
1. Is there a way for me to find out if there is planned fix for this issue?
2. If there is not a plan to fix this issue in an upcoming release, is there a
way I can find out if anyone else has submitted a fix?
3. If there there is no submitted fix, how would I go about submitting one
should I attempt a fix myself?
4. If I were to attempt a fix, I would likely not be able to spend a great deal
of time fully verifying it, given that this is outside of my usual job
responsibilities. Is there a way to submit a fix that others could help verify
- assuming that there are benevolent souls in the community that do this sort of
thing?
In short, please clue me in on the conventions of getting or making a fix to a
bug I care about. I am fine if the answer is "Read The Fine Manual", but do
please point me right manuals.
Many thanks in advance!
Best regards,
Rick Varney
Re: A fix for issue 3471
Posted by Rick Varney <rn...@yahoo.com>.
Many thanks for the replies on this. I now feel fully clued in.
Best regards,
Rick
Re: A fix for issue 3471
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Feb 22, 2011 at 3:20 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Tue, Feb 22, 2011 at 15:10:57 +0100:
>> On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
>> > Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
>> > > In particular note these two sections:
>> > > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
>> > > http://subversion.apache.org/docs/community-guide/general.html#patches
>> > > I found those two very valuable when I started out contributing to Subversion.
>> > >
>> >
>> > To be fair, #code-to-read has a mile-long list of header files, and I'm
>> > not sure that all of them are needed right away :)
>>
>> I did in fact spend a couple of days reading through them all before
>> I started writing any code. It did help a lot.
>
> The doc comments, sure. But the text sounds like it says "Read every
> docstring in those files", which isn't a good idea... (and IMO isn't as
> useful as reading the relevant notes/ files, where they exist)
I agree. That particular section was one of the major barriers for me
before getting started (well, apart from learning C, that is ;-)). I
almost gave up while stuck in read-mode ... Some people (like me) just
can't get any further before they have read and understood every
single line metioned there (and other files which are referred to from
the file being referred to, and so on ... until you've read half the
internet :-)). I admit I have punted on some of those ...
I think it would be better to get the big picture first, and then to
zoom in as quickly as possible to the area you're interested in, and
start experimenting. Trying to get your hands dirty as soon as
possible (diving into the code), while looking up stuff you don't
understand on a "need-to-understand" basis.
I think the community guide would benefit greatly from a refactoring
in this area, with the goal of lowering the barrier for potential
committers ... (though I admit I don't really have the time to have a
go at such a "refactoring" myself right now).
Cheers,
--
Johan
Re: A fix for issue 3471
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, Feb 22, 2011 at 15:10:57 +0100:
> On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> > > In particular note these two sections:
> > > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> > > http://subversion.apache.org/docs/community-guide/general.html#patches
> > > I found those two very valuable when I started out contributing to Subversion.
> > >
> >
> > To be fair, #code-to-read has a mile-long list of header files, and I'm
> > not sure that all of them are needed right away :)
>
> I did in fact spend a couple of days reading through them all before
> I started writing any code. It did help a lot.
The doc comments, sure. But the text sounds like it says "Read every
docstring in those files", which isn't a good idea... (and IMO isn't as
useful as reading the relevant notes/ files, where they exist)
Re: A fix for issue 3471
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 22, 2011 at 03:32:24PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> > In particular note these two sections:
> > http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> > http://subversion.apache.org/docs/community-guide/general.html#patches
> > I found those two very valuable when I started out contributing to Subversion.
> >
>
> To be fair, #code-to-read has a mile-long list of header files, and I'm
> not sure that all of them are needed right away :)
I did in fact spend a couple of days reading through them all before
I started writing any code. It did help a lot.
Re: A fix for issue 3471
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, Feb 22, 2011 at 10:27:24 +0100:
> In particular note these two sections:
> http://subversion.apache.org/docs/community-guide/general.html#code-to-read
> http://subversion.apache.org/docs/community-guide/general.html#patches
> I found those two very valuable when I started out contributing to Subversion.
>
To be fair, #code-to-read has a mile-long list of header files, and I'm
not sure that all of them are needed right away :)
Re: A fix for issue 3471
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 21, 2011 at 09:54:12PM -0800, Rick Varney wrote:
> Hello,
>
> I am introducing Subversion into our development environment. We are using a
> lock-modify-unlock stategy for all of our files. I do not claim this is the
> best or most efficient way to use Subversion, but it best fits the mindset of
> the developers at my particular site. We have installsed Subversion 1.6.6.
>
> We ran into the bug documented as issue 3471: "svn up touches file w/ lock &
> svn:keywords property"
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3471
>
> This is an annoyance for us, as we are using make to do our builds.
>
> I am new to the subversion community, though I have had my eye on it for a long
> time. Here are my questions:
>
> 1. Is there a way for me to find out if there is planned fix for this issue?
No, apart from asking here or on dev@.
You can never exactly know who is working on what in an open source
project because resources aren't being managed from a central point.
That said, I'm not aware of anybody having expressed interest in
working on this issue. But I don't know everything the community
is up to, either.
> 2. If there is not a plan to fix this issue in an upcoming release, is there a
> way I can find out if anyone else has submitted a fix?
Related patches will usually be logged to the issue.
Unless a patch has been submitted without people realising that there's
an issue filed for the problem. So again, you can never be sure :)
Searching the archives is the most reliable source of information about
past contributions. The archive at http://svn.haxx.se/dev has a search box.
> 3. If there there is no submitted fix, how would I go about submitting one
> should I attempt a fix myself?
This should get you started:
http://subversion.apache.org/contributing.html
In particular note these two sections:
http://subversion.apache.org/docs/community-guide/general.html#code-to-read
http://subversion.apache.org/docs/community-guide/general.html#patches
I found those two very valuable when I started out contributing to Subversion.
> 4. If I were to attempt a fix, I would likely not be able to spend a great deal
> of time fully verifying it, given that this is outside of my usual job
> responsibilities. Is there a way to submit a fix that others could help verify
> - assuming that there are benevolent souls in the community that do this sort of
> thing?
Yes, sure. We do encourage new contributors and try to help them
off the ground as much as possible. Sending a patch to dev@ will
usually trigger feedback right away. If it doesn't you can re-send
every couple of days letting people know that you haven't received any
feedback yet. We never ignore contributions on purpose. We have a patch
manager who takes care of contributions that have slipped through the
cracks in case submitters don't ping their own contributions:
http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
> In short, please clue me in on the conventions of getting or making a fix to a
> bug I care about. I am fine if the answer is "Read The Fine Manual", but do
> please point me right manuals.
>
> Many thanks in advance!
Hope this helps!
Stefan
>
> Best regards,
>
> Rick Varney
Re: A fix for issue 3471
Posted by Stephen Butler <sb...@elego.de>.
On Feb 22, 2011, at 6:54 , Rick Varney wrote:
> Hello,
>
> I am introducing Subversion into our development environment. We are using a lock-modify-unlock stategy for all of our files. I do not claim this is the best or most efficient way to use Subversion, but it best fits the mindset of the developers at my particular site. We have installsed Subversion 1.6.6.
>
> We ran into the bug documented as issue 3471: "svn up touches file w/ lock & svn:keywords property"
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3471
>
> This is an annoyance for us, as we are using make to do our builds.
>
> I am new to the subversion community, though I have had my eye on it for a long time. Here are my questions:
>
> 1. Is there a way for me to find out if there is planned fix for this issue?
Hi Rick,
There's a roadmap page for larger features,
http://subversion.apache.org/roadmap.html
but for a bug like this, find the issue in the tracker and ask on the
users' list (as you've done).
> 2. If there is not a plan to fix this issue in an upcoming release, is there a way I can find out if anyone else has submitted a fix?
The issue resolution would have been set to FIXED. Or there would
have been discussions on the developer list. So it looks like no one's
worked on the issue yet.
> 3. If there there is no submitted fix, how would I go about submitting one should I attempt a fix myself?
The community guide explains how to check out the source code,
read the key header files, hack the code, run the tests, join the
developer list, and submit a patch.
http://subversion.apache.org/docs/community-guide/
When you check out the Subversion source, see the INSTALL file
for the list of dependencies to install or build first.
> 4. If I were to attempt a fix, I would likely not be able to spend a great deal of time fully verifying it, given that this is outside of my usual job responsibilities. Is there a way to submit a fix that others could help verify - assuming that there are benevolent souls in the community that do this sort of thing?
There's already a client test mentioned in the issue. That's usually
the first step.
If you submit a patch, others will critique it and test it.
>
> In short, please clue me in on the conventions of getting or making a fix to a bug I care about. I am fine if the answer is "Read The Fine Manual", but do please point me right manuals.
It seems like you already have a clue. The community guide has
the information you need.
Cheers,
Steve
PS: Before you dive in, have you tried the "use-commit-times" option
in your Subversion client config file?
http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.config
--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194