Remove tools/buildbot from tarballs?
Ben Reser writes: > The 1.9.0-alpha2 release artifacts are now available for testing/signing. Is it worth stripping tools/buildbot from the tarball? The files are no real use in the tarball but they are not very big either, perhaps 12KB in the tarball and 248KB unpacked. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Behaviour of 'svn lock' in a read-only workspace
Ben Reser writes:
> Index: subversion/libsvn_client/locking_commands.c
> ===
> --- subversion/libsvn_client/locking_commands.c (revision 1579078)
> +++ subversion/libsvn_client/locking_commands.c (working copy)
> @@ -294,6 +294,12 @@ organize_lock_targets(const char **common_parent_u
> _("No common parent found, unable to operate
> "
>"on disjoint arguments"));
>
> + /* Make sure the working copy is writable before modifying the
> + * repository otherwise we'll have a lock token with no place to put it
> + * or won't be able to remove the local lock token. */
> + SVN_ERR(svn_wc__acquire_write_lock(NULL, wc_ctx, common_dirent, FALSE,
> + result_pool, scratch_pool));
> +
>/* Get the URL for each target (which also serves to verify that
> the dirent targets are sane). */
>target_urls = apr_array_make(scratch_pool, rel_targets->nelts,
> @@ -504,6 +510,9 @@ svn_client_lock(const apr_array_header_t *targets,
>SVN_ERR(svn_ra_lock(ra_session, path_revs, comment,
>steal_lock, store_locks_callback, &cb, pool));
>
> + if (base_dir)
> +SVN_ERR(svn_wc__release_write_lock(ctx->wc_ctx, base_dir, pool));
> +
>return SVN_NO_ERROR;
> }
>
> @@ -549,6 +558,9 @@ svn_client_unlock(const apr_array_header_t *target
>SVN_ERR(svn_ra_unlock(ra_session, path_tokens, break_lock,
> store_locks_callback, &cb, pool));
>
> + if (base_dir)
> +SVN_ERR(svn_wc__release_write_lock(ctx->wc_ctx, base_dir, pool));
> +
>return SVN_NO_ERROR;
> }
>
Is that is going to leave locks behind if an error occurs? We have
svn_wc__call_with_write_lock and SVN_WC__CALL_WITH_WRITE_LOCK that might
avoid that problem. However multiple working copy support, something
1.6 didn't have, makes it all more tricky.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Behaviour of 'svn lock' in a read-only workspace
On 3/18/14, 2:18 PM, Fergus Slorach wrote:
> In Subversion 1.6 'svn lock ' in a read-only workspace fails as expected
> and no lock is created either in the workspace or in the repository.
>
> In Svn 1.7/1.8 'svn lock ' still fails, but it creates a repository-side
> lock (see below). Is this a regression or was the change intentional?
>
>> svn st -u abc
> Status against revision: 1633
>> svn lock abc
> svn: E200031: sqlite[S8]: attempt to write a readonly database
> svn: E200031: Additional errors:
> svn: E200031: sqlite[S8]: attempt to write a readonly database
>> svn st -u abc
> O1633 abc
> Status against revision: 1633
I don't think it was deliberate, it's just a consequence of how locking works
and how WC-NG works.
We always open the SQLite database in write mode, and SQLite doesn't error out
if it doesn't have write access it just gives us the database in read-only
mode. This pushes the failure out until we actually try to write.
In the case of locking we don't try to write anything to the wc database until
we have a successful lock back from the server (actually we do it in callbacks
for each lock made). Thus the failure happens after the lock has already been
made on the server side.
With WCv1 we'd take out a write lock on the working copy before we'd execute
the lock on the server side. The relevant call in the 1.6.x code is the
svn_wc_adm_probe_open3() call in organize_lock_targets() in
subversion/libsvn_client/locking_commands.c (note it passes TRUE for if the
open should take out a write lock). This was rewritten for WC-NG in r879836.
I suspect Hyrum just didn't consider this error scenario when he rewrote this
code.
I took a stab at fixing this but haven't finished yet because it needs to
account for multiple working copies (the common_dirent doesn't have to be a
working copy) and needs appropriate cleanups so that the write locks are
cleaned up when there are recoverable failures (e.g. failures from the server
side). This at least solves the issue, while breaking a bunch of other things
per the limitations I mentioned above. I post it below in case someone else
gets around to finishing this before I do.
[[[
Index: subversion/libsvn_client/locking_commands.c
===
--- subversion/libsvn_client/locking_commands.c (revision 1579078)
+++ subversion/libsvn_client/locking_commands.c (working copy)
@@ -294,6 +294,12 @@ organize_lock_targets(const char **common_parent_u
_("No common parent found, unable to operate "
"on disjoint arguments"));
+ /* Make sure the working copy is writable before modifying the
+ * repository otherwise we'll have a lock token with no place to put it
+ * or won't be able to remove the local lock token. */
+ SVN_ERR(svn_wc__acquire_write_lock(NULL, wc_ctx, common_dirent, FALSE,
+ result_pool, scratch_pool));
+
/* Get the URL for each target (which also serves to verify that
the dirent targets are sane). */
target_urls = apr_array_make(scratch_pool, rel_targets->nelts,
@@ -504,6 +510,9 @@ svn_client_lock(const apr_array_header_t *targets,
SVN_ERR(svn_ra_lock(ra_session, path_revs, comment,
steal_lock, store_locks_callback, &cb, pool));
+ if (base_dir)
+SVN_ERR(svn_wc__release_write_lock(ctx->wc_ctx, base_dir, pool));
+
return SVN_NO_ERROR;
}
@@ -549,6 +558,9 @@ svn_client_unlock(const apr_array_header_t *target
SVN_ERR(svn_ra_unlock(ra_session, path_tokens, break_lock,
store_locks_callback, &cb, pool));
+ if (base_dir)
+SVN_ERR(svn_wc__release_write_lock(ctx->wc_ctx, base_dir, pool));
+
return SVN_NO_ERROR;
}
]]]
Re: 1.9.0-alpha2 up for testing/signing
On Wed, Mar 19, 2014 at 12:09 AM, Philip Martin wrote: > Ben Reser writes: > > > On 3/4/14, 1:23 AM, Ben Reser wrote: > >> The 1.9.0-alpha2 release artifacts are now available for > testing/signing. > >> Please get the tarballs from > >> https://dist.apache.org/repos/dist/dev/subversion > >> and add your signatures there. There's no particular schedule to this > it's > >> ready when it's ready. > > > > Vote count stands at: > > *nix: 2 > > Windows: 1 > > > > There hasn't been a vote in a while. Please test and vote if you get a > chance, > > there's no rush but it'd be nice to get this out. > > svnserve's SASL support is broken, see r1579080. It's a good to see that this alpha already uncovered a few feature breakages that we would usually not see before the first beta. > How important is > working SASL support? > Hm. I don't think this bug interferes with people's ability to test the new bits that we like to get feedback on. -- Stefan^2.
Re: 1.9.0-alpha2 up for testing/signing
Ben Reser writes: > On 3/4/14, 1:23 AM, Ben Reser wrote: >> The 1.9.0-alpha2 release artifacts are now available for testing/signing. >> Please get the tarballs from >> https://dist.apache.org/repos/dist/dev/subversion >> and add your signatures there. There's no particular schedule to this it's >> ready when it's ready. > > Vote count stands at: > *nix: 2 > Windows: 1 > > There hasn't been a vote in a while. Please test and vote if you get a > chance, > there's no rush but it'd be nice to get this out. svnserve's SASL support is broken, see r1579080. How important is working SASL support? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: client side workaround for svnserve iprops bug
Bert Huijben wrote on Tue, Mar 18, 2014 at 19:42:29 +0100: > > > > -Original Message- > > From: Philip Martin [mailto:philip.mar...@wandisco.com] > > Sent: dinsdag 18 maart 2014 19:32 > > To: dev@subversion.apache.org > > Subject: client side workaround for svnserve iprops bug > > > > phi...@apache.org writes: > > > > > Author: philip > > > Date: Tue Mar 18 12:57:22 2014 > > > New Revision: 1578853 > > > > > > URL: http://svn.apache.org/r1578853 > > > Log: > > > Make svnserve recognise when the client does not want inherited > > > properties. This fixes a performance problem with 1.8 servers > > > sending too much data. > > > > An implementation bug causes svnserve to mishandle the nominally > > optional want-iprops flag for get-dir and get-file with the result that > > the server keeps sending properties even when the client doesn't want > > them, this can be a serious performance regression. (The want-iprops > > flags was documented/released with 1.8 but isn't used by the released > > client which uses get-iprops instead.) The problem is fixed on trunk > > and nominated for 1.8 with 1578853. > > > > We could add a client-side workaround for buggy servers, see the patch > > below. We could do this for trunk, 1.8, even 1.7. Is it a good thing > > to do? > > If think affected users should upgrade (or downgrade) their server to a not > affected server. > > If it the performance was a real show stopper we would have known about this > problem months earlier. > It's a small patch that's unlikely to break anything (regardless of server version) and may make some users' lives easier. Seems to me like a good backport candidate. > For 1.8 a few more user reports can convince me that it would be useful to > add it, but for svnserve it would be easier to fix a single server than all > the clients. (It isn't that connected to all kinds of other modules as > mod_dav_svn). > > Adding a protocol changing patch to 1.7 to improve performance against a > specific set of 1.8 servers... I don't think we should go that route. In > that case we could better spend our time backporting many of the far more > important move bugs in 1.8 (several that can corrupt wc.db) that were fixed > months ago from trunk... Or the ra_serf fixes... Don't let the perfect be the enemy of the good. Backporting an ra_svn bugfix is an improvement. If people want to backport ra_serf bugfixes, that's great... but the fact that no one backported ra_serf fixes isn't really a good reason to block ra_svn fixes. --- I would vote "+1 to backport" right here and now, but I'm a bit confused by the patch: it seems the client and server send and expect a bare boolean, whereas libsvn_ra_svn/protocol calls for a boolean wrapped in a tuple. (i.e., '( foo bar true ) ' vs '( foo bar ( true ) ) '.
Behaviour of 'svn lock' in a read-only workspace
Hi, In Subversion 1.6 'svn lock ' in a read-only workspace fails as expected and no lock is created either in the workspace or in the repository. In Svn 1.7/1.8 'svn lock ' still fails, but it creates a repository-side lock (see below). Is this a regression or was the change intentional? > svn st -u abc Status against revision: 1633 > svn lock abc svn: E200031: sqlite[S8]: attempt to write a readonly database svn: E200031: Additional errors: svn: E200031: sqlite[S8]: attempt to write a readonly database > svn st -u abc O1633 abc Status against revision: 1633 All the best, fergus
Re: 1.9.0-alpha2 up for testing/signing
On 3/18/14, 9:52 AM, Johan Corveleyn wrote: > I get one failure when testing with FSX: > > [[[ > svn_tests: E160057: Node revision index 26 exceeds container size 26 > FAIL: fs-x-pack-test.exe 3: read from a packed FSX filesystem > ]]] > > Anyone else seeing this? Look the same as this to me: https://mail-archives.apache.org/mod_mbox/subversion-dev/201403.mbox/%3C531A45B7.9010304%40reser.org%3E Can you see if r1575642 resolves this for you? I'm not overly concerned with FSX issues since it's entirely experimental at this point.
Re: copy repository question
Hello, On 18/03/14 02:49, rvaedex23 wrote: > I am trying to copy a repository to another location. > Example > copy > > /export/svn/repo1 > > to > > /export/svn/repo2/code/documents/repo1 > how can this be done in Linux? For usage questions, please contact the us...@subversion.apache.org mailing list. https://subversion.apache.org/mailing-lists.html#users-ml With kind regards, Andreas Stieger
RE: client side workaround for svnserve iprops bug
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: dinsdag 18 maart 2014 19:32 > To: dev@subversion.apache.org > Subject: client side workaround for svnserve iprops bug > > phi...@apache.org writes: > > > Author: philip > > Date: Tue Mar 18 12:57:22 2014 > > New Revision: 1578853 > > > > URL: http://svn.apache.org/r1578853 > > Log: > > Make svnserve recognise when the client does not want inherited > > properties. This fixes a performance problem with 1.8 servers > > sending too much data. > > An implementation bug causes svnserve to mishandle the nominally > optional want-iprops flag for get-dir and get-file with the result that > the server keeps sending properties even when the client doesn't want > them, this can be a serious performance regression. (The want-iprops > flags was documented/released with 1.8 but isn't used by the released > client which uses get-iprops instead.) The problem is fixed on trunk > and nominated for 1.8 with 1578853. > > We could add a client-side workaround for buggy servers, see the patch > below. We could do this for trunk, 1.8, even 1.7. Is it a good thing > to do? If think affected users should upgrade (or downgrade) their server to a not affected server. If it the performance was a real show stopper we would have known about this problem months earlier. For 1.8 a few more user reports can convince me that it would be useful to add it, but for svnserve it would be easier to fix a single server than all the clients. (It isn't that connected to all kinds of other modules as mod_dav_svn). Adding a protocol changing patch to 1.7 to improve performance against a specific set of 1.8 servers... I don't think we should go that route. In that case we could better spend our time backporting many of the far more important move bugs in 1.8 (several that can corrupt wc.db) that were fixed months ago from trunk... Or the ra_serf fixes... Bert
client side workaround for svnserve iprops bug
phi...@apache.org writes: > Author: philip > Date: Tue Mar 18 12:57:22 2014 > New Revision: 1578853 > > URL: http://svn.apache.org/r1578853 > Log: > Make svnserve recognise when the client does not want inherited > properties. This fixes a performance problem with 1.8 servers > sending too much data. An implementation bug causes svnserve to mishandle the nominally optional want-iprops flag for get-dir and get-file with the result that the server keeps sending properties even when the client doesn't want them, this can be a serious performance regression. (The want-iprops flags was documented/released with 1.8 but isn't used by the released client which uses get-iprops instead.) The problem is fixed on trunk and nominated for 1.8 with 1578853. We could add a client-side workaround for buggy servers, see the patch below. We could do this for trunk, 1.8, even 1.7. Is it a good thing to do? Index: subversion/libsvn_ra_svn/client.c === --- subversion/libsvn_ra_svn/client.c (revision 1578900) +++ subversion/libsvn_ra_svn/client.c (working copy) @@ -1371,7 +1371,10 @@ static svn_error_t *ra_svn_get_dir(svn_ra_session_ if (dirent_fields & SVN_DIRENT_LAST_AUTHOR) SVN_ERR(svn_ra_svn__write_word(conn, pool, SVN_RA_SVN_DIRENT_LAST_AUTHOR)); - SVN_ERR(svn_ra_svn__write_tuple(conn, pool, "!))")); + /* Always send the, nominally optional, want-iprops as "false" to + workaround a bug in svnserve 1.8.0-1.8.9 that causes the server + to see "true" if it omitted. */ + SVN_ERR(svn_ra_svn__write_tuple(conn, pool, "!)b)", FALSE)); SVN_ERR(handle_auth_request(sess_baton, pool)); SVN_ERR(svn_ra_svn__read_cmd_response(conn, pool, "rll", &rev, &proplist, Index: subversion/libsvn_ra_svn/marshal.c === --- subversion/libsvn_ra_svn/marshal.c (revision 1578900) +++ subversion/libsvn_ra_svn/marshal.c (working copy) @@ -2092,7 +2092,10 @@ svn_ra_svn__write_cmd_get_file(svn_ra_svn_conn_t * SVN_ERR(write_tuple_end_list(conn, pool)); SVN_ERR(write_tuple_boolean(conn, pool, props)); SVN_ERR(write_tuple_boolean(conn, pool, stream)); - SVN_ERR(writebuf_write_short_string(conn, pool, ") ) ", 4)); + /* Always send the, nominally optional, want-iprops as "false" to + workaround a bug in svnserve 1.8.0-1.8.9 that causes the server + to see "true" if it omitted. */ + SVN_ERR(writebuf_write_short_string(conn, pool, " false ) ) ", 11)); return SVN_NO_ERROR; } -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: 1.9.0-alpha2 up for testing/signing
On Sun, Mar 16, 2014 at 11:23 PM, Johan Corveleyn wrote: > On Fri, Mar 14, 2014 at 4:46 PM, Ben Reser wrote: >> On 3/4/14, 1:23 AM, Ben Reser wrote: >>> The 1.9.0-alpha2 release artifacts are now available for testing/signing. >>> Please get the tarballs from >>> https://dist.apache.org/repos/dist/dev/subversion >>> and add your signatures there. There's no particular schedule to this it's >>> ready when it's ready. >> >> Vote count stands at: >> *nix: 2 >> Windows: 1 >> >> There hasn't been a vote in a while. Please test and vote if you get a >> chance, >> there's no rush but it'd be nice to get this out. >> > > I'll probably be able to test / vote on Windows sometime during the coming > week. I get one failure when testing with FSX: [[[ svn_tests: E160057: Node revision index 26 exceeds container size 26 FAIL: fs-x-pack-test.exe 3: read from a packed FSX filesystem ]]] Anyone else seeing this? -- Johan
RE: Subversion checked-out files not indexed in Windows search
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: dinsdag 18 maart 2014 11:37 > To: 'Subversion Development' > Subject: Re: Subversion checked-out files not indexed in Windows search > > On 18.03.2014 11:20, Bert Huijben wrote: > > But the reason we set this flag is mostly gone anyway... I think we should > just remove our code to touch that attribute and use the apr attribute > function like we did before. The additional indexing is not really our problem > (and the indexer won't care about a few more MB), and it is very easy to > filter on *.svn-base if somebody want that. > > Dunno ... I think any indexing in the .svn directory is a mistake and > likely to cause confusion. Not because of performance degradation, but > because users really shouldn't care about the contents of that > directory, including not seeing them in search results. > > Of course, tweaking that flag when the file is renamed has its own set > of "interesting" problems ... for example, we'd have to check the flag > and inheritance settings on the parent directory. We are not the one indexing :) The attribute is just a hint supported by some of the possible indexers (many have positive and negative overrides). On some filesystems the flag isn't even supported. Introducing a second tmp directory to create pristine files in (perhaps below .svn/pristine) would allow setting the flag just for the pristine files. I'm not sure if that really requires a format bump... We could just clean it like .svn/tmp when there are no locks and no working queue items. Bert
Re: Subversion checked-out files not indexed in Windows search
On 18.03.2014 11:20, Bert Huijben wrote: > But the reason we set this flag is mostly gone anyway... I think we should > just remove our code to touch that attribute and use the apr attribute > function like we did before. The additional indexing is not really our > problem (and the indexer won't care about a few more MB), and it is very easy > to filter on *.svn-base if somebody want that. Dunno ... I think any indexing in the .svn directory is a mistake and likely to cause confusion. Not because of performance degradation, but because users really shouldn't care about the contents of that directory, including not seeing them in search results. Of course, tweaking that flag when the file is renamed has its own set of "interesting" problems ... for example, we'd have to check the flag and inheritance settings on the parent directory. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: Subversion checked-out files not indexed in Windows search
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: dinsdag 18 maart 2014 11:07 > To: Bert Huijben > Cc: Branko Čibej; Subversion Development > Subject: Re: Subversion checked-out files not indexed in Windows search > > On 13 March 2014 17:14, Bert Huijben wrote: > > > > > >> -Original Message- > >> From: Ivan Zhakov [mailto:i...@visualsvn.com] > >> Sent: donderdag 13 maart 2014 13:56 > >> To: Branko Čibej > >> Cc: Subversion Development > >> Subject: Re: Subversion checked-out files not indexed in Windows search > >> > >> On 13 March 2014 16:46, Branko Čibej wrote: > >> > On 13.03.2014 13:37, Ivan Zhakov wrote: > >> > > >> > On 12 March 2014 18:17, Gareth McCaughan > >> > wrote: > >> > > >> > Ivan Zhakov wrote: > >> > > >> > It looks like serious issue. Could you please file issue in Subversion > >> > issue tracker: http://subversion.tigris.org/issues > >> > > >> > Done. Issue #4478. > >> > > >> > Gareth, thanks a lot! > >> > > >> > It seems we have second reason to create temporary files in target WC > >> > directory, instead of .svn/tmp. Another problem we had before is > >> > inherited ACL on Windows discussed year ago: > >> > http://mail-archives.apache.org/mod_mbox/subversion- > >> > dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6 > >> .be88925bf6.wbe%40email16.secureserver.net%3E > >> > > >> > I've prepared stupid patch to create temporary files in WC, instead of > >> > .svn/tmp and it seems working fine. > >> > > >> > > >> > -1. This leaves us with no reliable way to clean up the working copy in > case > >> > of an aborted operation. > >> > > >> > There should be a better way for managing ACLs on windows that does > not > >> > require us to mess up the working copy. I'm perfectly happy with just > >> > documenting that we don't support different ACLs for .svn and the rest > of > >> > the WC, at least for now. > >> > > >> Please note that problem reported is not about inherited ACL: now > >> users got NOT_INDEXED attribute on all WC files, because .svn marked > >> to by not indexed by Windows Search and tools like that. > > > > I'm working on a better patch for this, that doesn't have this problem and > > will improve performance on the pristine store operations as well. > That's good news. Could you please share idea of your patch? > > I'm thinking of something like this: > 1. Create temp file in target directory. > 2. Set DELETE_ON_CLOSE=TRUE using SetFileInformationByHandle() > 3. Write contents to temporary file > 4. Set DELETE_ON_CLOSE=FALSE using SetFileInformationByHandle() > 5. Rename to final location using SetFileInformationByHandle() > 6. Delete if failed. > 7. CloseFile() The idea I was working on didn't involve creating files in locations where they could work against us in a case of a crash. I don't think delete on close will be handled on system failures, just on application failures. The original reason to set the NOT_INDEXED flag on the .svn subdirectory (patches by stefanking and you), was that this caused quite a huge slowdown as the file indexer on Windows 7 and XP continuously monitors for changes and started indexing the file even before we moved it in place. (Even triggering an NTFS bug in Windows 7 pre SP 1) The new install code keeps the file under a full lock that allows us to move the file in place without outside handling of a file. (A virusscanner can still read it while we have it open, but as we already have the move and delete privileges we don't have to wait to obtain move rights). I think we should stick to the original (far pre Subversion 1.0) model of creating files in the .svn wc directories, for the same reason Brane alreadt vetoed your idea of creating the files in the directory. The reasoning behind that is very solid. That some users want to see permissions different than in all previous versions is not a good reason to slow things down (another open, ACL check, ACL update, close) and/or to make the working copy less stable (possibility of files in the working copy that hides real changes and are easily to accidentally commit). We never touched ACLs, on any platforms... I don't think we should start with doing that, especially at a performance cost. I hoped that for the non-indexing bit we could just pass the attribute to CreateFileW(), but this function explicitly ignores this attribute. It only applies it from the parent directory. Using a different tempdir for creating new pristine files would work. But the reason we set this flag is mostly gone anyway... I think we should just remove our code to touch that attribute and use the apr attribute function like we did before. The additional indexing is not really our problem (and the indexer won't care about a few more MB), and it is very easy to filter on *.svn-base if somebody want that. Bert > > This will be Windows Vista only code since > SetFileInformationByHandle() is not available for older platfo
Re: Subversion checked-out files not indexed in Windows search
On 13 March 2014 17:14, Bert Huijben wrote: > > >> -Original Message- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: donderdag 13 maart 2014 13:56 >> To: Branko Čibej >> Cc: Subversion Development >> Subject: Re: Subversion checked-out files not indexed in Windows search >> >> On 13 March 2014 16:46, Branko Čibej wrote: >> > On 13.03.2014 13:37, Ivan Zhakov wrote: >> > >> > On 12 March 2014 18:17, Gareth McCaughan >> > wrote: >> > >> > Ivan Zhakov wrote: >> > >> > It looks like serious issue. Could you please file issue in Subversion >> > issue tracker: http://subversion.tigris.org/issues >> > >> > Done. Issue #4478. >> > >> > Gareth, thanks a lot! >> > >> > It seems we have second reason to create temporary files in target WC >> > directory, instead of .svn/tmp. Another problem we had before is >> > inherited ACL on Windows discussed year ago: >> > http://mail-archives.apache.org/mod_mbox/subversion- >> dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6 >> .be88925bf6.wbe%40email16.secureserver.net%3E >> > >> > I've prepared stupid patch to create temporary files in WC, instead of >> > .svn/tmp and it seems working fine. >> > >> > >> > -1. This leaves us with no reliable way to clean up the working copy in >> > case >> > of an aborted operation. >> > >> > There should be a better way for managing ACLs on windows that does not >> > require us to mess up the working copy. I'm perfectly happy with just >> > documenting that we don't support different ACLs for .svn and the rest of >> > the WC, at least for now. >> > >> Please note that problem reported is not about inherited ACL: now >> users got NOT_INDEXED attribute on all WC files, because .svn marked >> to by not indexed by Windows Search and tools like that. > > I'm working on a better patch for this, that doesn't have this problem and > will improve performance on the pristine store operations as well. That's good news. Could you please share idea of your patch? I'm thinking of something like this: 1. Create temp file in target directory. 2. Set DELETE_ON_CLOSE=TRUE using SetFileInformationByHandle() 3. Write contents to temporary file 4. Set DELETE_ON_CLOSE=FALSE using SetFileInformationByHandle() 5. Rename to final location using SetFileInformationByHandle() 6. Delete if failed. 7. CloseFile() This will be Windows Vista only code since SetFileInformationByHandle() is not available for older platforms. But newer Windows SDKs has compatibility library FileExtd.lib for Windows XP. > > But since when is this a huge problem? We applied this setting since 1.6 if I > remember correctly... > I'm more surprised that you didn't know about this? > I think setting NOT_INDEXED attribute is big problem, while ACL is nice to have but not so critical. I was not aware about this problem before. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
