Hello kfogel,
ANOTHER ISSUE, _PLEASE_ FIND 1 min to read this letter....
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:
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.
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.
I attach patch file for SVN 1.1 that makes all that I describe. Please
_ANYBODY_ response to this.
Wednesday, October 13, 2004, 8:22:05 PM, you wrote:
kcn> Andrew n marshall <amarshal@ISI.EDU> writes:
>> Searching the web, I came up with this:
>> http://www.pushok.com/soft_svn_vscvs.php
>> but it is undated. Are the comments provided still accurate?
kcn> The statements of fact there are mostly accurate (some of the opinions
kcn> I disagree with, but that's okay). There are a couple of mistakes,
kcn> though. I've CC'd PushOk's webmaster here, in case they want to make
kcn> corrections.
kcn> First, the paragraph about SVN tagging:
kcn> "The SVN developers assert with pride that they have got rid of 3
kcn> measurements by working with tags and branches. In practice it
kcn> means that they have substituted both concepts for a capability of
kcn> copying file(s) or directories within the repository with saving
kcn> the history of changes. That is, both tag creation and branch
kcn> creation are substituted for copying within the repository. From
kcn> the SVN developers' viewpoint, this is very elegant decision, which
kcn> simplifies one's life. However, we think that there is nothing to
kcn> be proud of. As for branches, everything is not so bad, now
kcn> branches are nothing but separate folders in the repository, which
kcn> earlier have had some interconnection. As for tags, everything is
kcn> much worse. Now you cannot tag a code, this function is simply
kcn> missing. Certainly, to some extent this is compensated by universal
kcn> numbering of files in SVN, that is, the whole repository gets the
kcn> version number, but not each separate file. However, we suppose you
kcn> will not deny that it is not very convenient to store a four-digit
kcn> number instead of a symbolic tag."
kcn> The assertion "you cannot tag a code, the function is simply missing"
kcn> is false. I don't know why they think you can't tag code. In
kcn> Subversion, as in CVS, you can tag a working copy to get a repository
kcn> structure that represents the exact mixed-version state of that
kcn> working copy. Or you can tag a state that's already in the
kcn> repository, again just as with CVS.
kcn> I also don't know what the last sentence means. Subversion tags are
kcn> not four-digit numbers, they are UTF8 strings. Any CVS tag name can
kcn> use the same name in Subversion.
kcn> While Subversion's *representation* of tags is slightly different,
kcn> Subversion tags do basically the same things as CVS's. Maybe I'm just
kcn> misunderstanding what PushOk is trying to say above, but the most
kcn> natural interpretations do seem to be false.
kcn> The other mistake is quite understandable, as the FSFS (non-Berkeley)
kcn> repository was probably not available at the time they wrote this:
kcn> "The basis of SVN is a relational database (BerkleyDB). On one
kcn> hand, this settles many problems (for example, concurrent access
kcn> through the file share) and enables new functionalities (for
kcn> example, transactions at operations performance). However, on the
kcn> other hand, data storage now is not transparent, or at least is not
kcn> available for user interference. That is why the utilities for
kcn> 'curing' and 'recovering' of the repository (database) are
kcn> provided."
kcn> Note also that BerkeleyDB is not a "relational database". It's a data
kcn> storage/retrieval mechanism, without relational capabilities.
kcn> Anyway, BerkeleyDB is now one of two options for repository storage.
kcn> I'd also like to point out that the locking/reserved-checkouts
kcn> discussion now under way will soon give us one of the missing features
kcn> PushOk's page talks about the most: CVS's edit/watch functionality.
kcn> -Karl
--
Best regards,
pushok mailto:contact@pushok.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 22 16:37:00 2004