[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Re[2]: CVS/SVN comparison

From: <kfogel_at_collab.net>
Date: 2004-10-22 15:54:20 CEST

pushok <contact@pushok.com> writes:
> Hello kfogel,
> ANOTHER ISSUE, _PLEASE_ FIND 1 min to read this letter....

No need to beg, I'm reading the mails :-).

> I wonder how we can submit patches for you SVN. More exactly, I claim
> "there is bad thing in your code for read-only flag on windows".
> Anybody (from 20 developers of SVN) interested to know about this?
> I already submit this patch to your dev list, but all just ignore
> it (nice). So the problems we have:

That sometimes happens, it's nothing personal. You can make the patch
more attractive by including a log message. See the guidelines in
http://svn.collab.net/repos/svn/trunk/HACKING about submitting patches
and writing log messages, thanks.

> 1. SVN shows error when tries to update read-only files.
> 2. Our plug-in wants to have not modified files read-only, since that
> expect behavior.
> What we found in SVN code and what we make:
> 1. We found that you already have problems with that behavior (update
> of read-only files). And implement dummy and bad patch for this -
> function "svn_wc__prep_file_for_replacement". It makes nothing for all
> platform and only for Windows remove the read-only flag. So, in
> critical places you put code like this:
> SVN_ERR (svn_wc__prep_file_for_replacement (basef, TRUE, pool));
> SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
> SVN_ERR (svn_io_set_file_read_only (basef, FALSE, pool));
> LOOKS STRANGE, RIGHT?
> So, we just follow the linux rules, that allows to rename file if it
> is read-only and make patch for your rename function. This way all
> works now fine:
> * not need to have the svn_wc__prep_file_for_replacement, it is
> just delete
> * the code above now looks like
> SVN_ERR (svn_io_file_rename (tmpf, basef, pool));
> * readonly correctly handled on widnows. SVN do not show error
> updating it and basic rule is: if file readonly it will remain
> readonly after update, if writable, it will remain writable.

I think there were some reasons we did things this way, but I can't
remember what they were now. Can you try asking on the dev@ list in a
new thread?

> 2. We also make patch (few small things) that allow SVN mimics CVS
> "Checkout file readonly". I.e. pull new files as readonly, make them
> readonly after commit. This way not edited files are readonly which
> is very good for IDE. All changed about that are paced in "#ifdef
> SVN_CLIENT_CHECKOUT_READONLY" blocks. I not suggest to make this, if
> you not want, this is extra functionality. However taking into account
> your new goal for SVN 1.2 this may be useful.

A separate patch for this would be better than mixing it in with the
other changes.

> I attach patch file for SVN 1.1 that makes all that I describe. Please
> _ANYBODY_ response to this.

Post to dev@ list with "[PATCH]" in the subject. Post a separate
email for each logically separate change. Include a log message for
each patch.

I don't know when you posted the patches last time, but we have a
patch manager now who does a very thorough job of making sure patches
don't get lost.

Thanks,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 22 17:46:01 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.