Re: .svn/wc.db as group writable
On Fri, Feb 24, 2017 at 2:03 AM, Branko Čibej wrote: > On 23.02.2017 23:59, Stefan wrote: >> On 2/22/2017 17:13, Carlos Adean wrote: >>> Hello, >>> >>> >>> - Mensagem original - De: "Stefan Hett" Para: users@subversion.apache.org Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36 Assunto: Re: .svn/wc.db as group writable On 2/20/2017 1:40 PM, Carlos Adean wrote: On the specific issue: I'm not getting completely what problem you are facing. Are you expecting that SVN sets the group for .svn/wc.db according to some group you set up by itself so it's readably/usable by other users than the one who did the repository checkout? Regards, Stefan > So, I have set umask 002 and it works for all files except on > .svn/wc.db - maybe I'm wrong and this is not a SVN problem. > > > Again, I know this is unusual situation but is how we need to work. > >> Can you be a bit more specific what exactly you mean by "That's the >> file that causes the problem[...]"? Do you get an SVN error when you >> perform some operation from different accounts on the working copy >> (in that case, please state the exact error message)? Alternatively: >> Are you suggesting that after performing an SVN operation the >> permissions of .svn/wc.db are changed (to what they were before the >> call)? >>> The default umask is 002 for all users and all of them are in the same >>> group 'appgroup', which is the group that owns the repositories. The >>> repositories are remote and one specific user creates local copies/clones. >>> This user checks out a repository in a given directory (e.g. >>> /home/appuser/software/trunk) using his own account. If a different user >>> tries to svn update the same local copy of the repository, he gets errors >>> of the type: >>> >>> svn: E155004: Working copy '/home/appuser/software/trunk' locked >>> svn: E200031: sqlite: attempt to write a readonly database >>> svn: E200031: sqlite: attempt to write a readonly database >>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) >>> >>> my doubt is: if the umask is 002 why are the permissions for the group >>> read-only on that file after checkout? >>> >> It certainly looks like some permission setup on your environment to me. >> I don't have a test Linux machine running atm, so I can't test; but I'd >> assume that files created in the user's home directly by default are >> only granted full access by the current user, no? [1] > > No. They're granted whatever access is allowed by the umask. See > https://en.wikipedia.org/wiki/Umask > > If the umask is 002 then all created files will, by default, allow read > and write access to the user and the user's primary group. Neither > Subversion nor SQLite tries to be smart in any way in this respect. > > There are other ways to control permissions on new files: your > filesystem could have inheritable ACLs that prevent group-write > permission to be granted, regardless of umask. Your SELinux > configuration could do that, too. > > In any case, this is not a Subversion bug. I can confirm that this "should work". At work we have a shared build machine (Solaris), with hundreds of working copies for all kinds of builds. All our developers can run builds there (including updating those working copies or performing various working copy operations). We're all part of the same unix group, and all use umask 002 on that machine. This works fine (we've done this since SVN 1.5, we're now on 1.9.3). This is what 'ls -l' says about it: [[[ $ ls -l .svn total 160146 -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 entries -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 format drwxrwxr-x 258 johndoe devgrp 258 Mar 21 2014 pristine/ drwxrwxr-x 2 johndoe devgrp2 Feb 23 18:03 tmp/ -rw-rw-r-- 1 johndoe devgrp 81847296 Feb 23 18:03 wc.db -rw-rw-r-- 1 johndoe devgrp0 Feb 23 18:03 wc.db-journal ]]] -- Johan
Re: .svn/wc.db as group writable
On Thu, Feb 23, 2017 at 8:03 PM, Branko Čibej wrote: > No. They're granted whatever access is allowed by the umask. See > https://en.wikipedia.org/wiki/Umask > > If the umask is 002 then all created files will, by default, allow read > and write access to the user and the user's primary group. Neither > Subversion nor SQLite tries to be smart in any way in this respect. > > There are other ways to control permissions on new files: your > filesystem could have inheritable ACLs that prevent group-write > permission to be granted, regardless of umask. Your SELinux > configuration could do that, too. > > In any case, this is not a Subversion bug. > > -- Brane SELinux, perhaps? Check "/etc/sysconfig/selinux" and prepare to reset it to "warning" mode, and check the logs for SELinux errors? And there are other compelling reasons to avoid putting shared workspaces in individual user home directories.
Re: .svn/wc.db as group writable
On Fri, Feb 24, 2017 at 5:17 AM, Johan Corveleyn wrote: > [[[ > $ ls -l .svn > total 160146 > -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 entries > -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 format > drwxrwxr-x 258 johndoe devgrp 258 Mar 21 2014 pristine/ > drwxrwxr-x 2 johndoe devgrp2 Feb 23 18:03 tmp/ > -rw-rw-r-- 1 johndoe devgrp 81847296 Feb 23 18:03 wc.db > -rw-rw-r-- 1 johndoe devgrp0 Feb 23 18:03 wc.db-journal > ]]] You're definitely gont to want to set the directory permissions to "2775", in order to ensure that files created inside the subdirectory inherit the correct group permissions. Perhaps a "find . ! -group devgrp" might show such files, if they already exist?
Re: .svn/wc.db as group writable
On Fri, Feb 24, 2017 at 3:07 PM, Nico Kadel-Garcia wrote: > On Fri, Feb 24, 2017 at 5:17 AM, Johan Corveleyn wrote: > >> [[[ >> $ ls -l .svn >> total 160146 >> -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 entries >> -rw-rw-r-- 1 johndoe devgrp3 Mar 21 2014 format >> drwxrwxr-x 258 johndoe devgrp 258 Mar 21 2014 pristine/ >> drwxrwxr-x 2 johndoe devgrp2 Feb 23 18:03 tmp/ >> -rw-rw-r-- 1 johndoe devgrp 81847296 Feb 23 18:03 wc.db >> -rw-rw-r-- 1 johndoe devgrp0 Feb 23 18:03 wc.db-journal >> ]]] > > You're definitely gont to want to set the directory permissions to > "2775", in order to ensure that files created inside the subdirectory > inherit the correct group permissions. Perhaps a "find . ! -group > devgrp" might show such files, if they already exist? Thanks for the suggestion ... maybe I'll look into it. But for now this doesn't pose a problem for us, because we always set umask to 002 when devs login to this build machine, so any files they create beneath those directories, or anywhere else when they do "build-work", will be fine. (there have been some rare occurrences when a dev changed their umask, and then this falls over ... but we deal with those ad hoc for the moment) -- Johan
SVN log --revision "{2017-02-23T18:53Z}:{2017-02-24T02:46:15.225107Z}" not parsing date correctly?
I'm running a script on a scheduled basis where each new iteration I'm
essentially checking against a newer time from the last check-in, so if the
last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
ticks to that after that in terms of the revision to retrieve everything
after that last check-in time via the svn log command. Generally this is
working great, but the actual results from the command aren't always
consistent. Sometimes the return results will include stuff that's
obviously before the provided start date. I initially was adding ticks,
then I added a second, and now even in the below command I'm getting
inconsistent results whereby it's returning something that's a full 20
minutes before the command inputted... So I'm at a loss--is this a parsing
error, is this date not really compliant (I believe it is...), etc.? I've
tried consolidating the date format to just 2017-02-23T18:52Z etc as well
and it doesn't matter.
The exactly command (slightly redacted here) I'm running is:
svn.exe log --non-interactive --trust-server-cert --username ""
--password "*" --revision
"{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}" --verbose --xml
"https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48";
"DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"
and the resultant XML is:
returning two items within that, the first of which should be there and one
which is before the provided time:
oooy
2017-02-23T18:51:15.175583Z
/branches/SynergyR1.48/DOTNET/A/Synergy
...
oooyb
2017-02-24T02:46:15.225107Z
I've been manually running this command from windows on multiple machines
w/ same result. I have latest tortoise client on at least 2 of the machines
but SVN server itself is version 1.8.11r1643975. I don't see anything too
obvious in the change log since that seems relevant to this though if it
were a bug.
So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
start time and the very specific point in start time at which it goes from
including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
to: {2017-02-23T19:06:02.41248Z} ... That's roughly shy of exactly 15
minutes after the actual checked time time. What is going on here w/ this
parsing? Again to clarify though even the simpler format
{2017-02-23T18:53Z} fails to properly parse as that includes the check-in
when it shouldn't. I've also tried a simple end date/time and that doesn't
affect the results.
Anyone have any suggestions or what to try to track this down? Given the
time
Re: SVN log --revision "{2017-02-23T18:53Z}:{2017-02-24T02:46:15.225107Z}" not parsing date correctly?
That's an interesting one.
I don't know why you're seeing the behavior you're seeing. However, I can
tell you that relying on the date is probably a mistake. Instead, better to
capture the revision # for the repository, and log for revision #s after
the last one you got. There are scenarios in which the svn:date information
recorded with a revision need not appear in strict chronological order.
I've run into this after combining repositories with svn:load.
Also it is possible to either change an svn:date property (svnadmin propset
...), or remove it altogether. In other words, depending on what you allow
of the repository clients, the date is not a reliable indicator of "changed
since".
Eric.
On Fri, Feb 24, 2017 at 10:08 AM, Dane Kantner
wrote:
> I'm running a script on a scheduled basis where each new iteration I'm
> essentially checking against a newer time from the last check-in, so if the
> last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
> ticks to that after that in terms of the revision to retrieve everything
> after that last check-in time via the svn log command. Generally this is
> working great, but the actual results from the command aren't always
> consistent. Sometimes the return results will include stuff that's
> obviously before the provided start date. I initially was adding ticks,
> then I added a second, and now even in the below command I'm getting
> inconsistent results whereby it's returning something that's a full 20
> minutes before the command inputted... So I'm at a loss--is this a parsing
> error, is this date not really compliant (I believe it is...), etc.? I've
> tried consolidating the date format to just 2017-02-23T18:52Z etc as well
> and it doesn't matter.
>
> The exactly command (slightly redacted here) I'm running is:
>
> svn.exe log --non-interactive --trust-server-cert --username ""
> --password "*" --revision
> "{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}"
> --verbose --xml
> "https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48";
> "DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"
>
>
> and the resultant XML is:
> returning two items within that, the first of which should be there and
> one which is before the provided time:
>
>
>
>
>
> revision="54437">
> oooy
> 2017-02-23T18:51:15.175583Z
>
> action="M"
>prop-mods="true"
>text-mods="false"
>kind="dir">/branches/SynergyR1.48/DOTNET/A/Synergy
> ...
> revision="54442">
> oooyb
> 2017-02-24T02:46:15.225107Z
>
>
> I've been manually running this command from windows on multiple machines
> w/ same result. I have latest tortoise client on at least 2 of the machines
> but SVN server itself is version 1.8.11r1643975. I don't see anything too
> obvious in the change log since that seems relevant to this though if it
> were a bug.
>
> So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
> start time and the very specific point in start time at which it goes from
> including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
> to: {2017-02-23T19:06:02.41248Z} ... That's roughly shy of exactly 15
> minutes after the actual checked time time. What is going on here w/ this
> parsing? Again to clarify though even the simpler format
> {2017-02-23T18:53Z} fails to properly parse as that includes the check-in
> when it shouldn't. I've also tried a simple end date/time and that doesn't
> affect the results.
>
>
> Anyone have any suggestions or what to try to track this down? Given the
> time
>
Re: SVN log --revision "{2017-02-23T18:53Z}:{2017-02-24T02:46:15.225107Z}" not parsing date correctly?
True except in my environment those are non issue as we control it pretty
tightly with process (and I would assume most professional development
shops are under similar constraints?). I actually started with revision
numbers but I wanted to specifically use the date time and not revision
number for modularity of then also having the functionality to pull by date
time specifically in script. But I suppose I can go the route of using
revision number in the same function but also build a wrapper for that
other functionality to determine revision number at the time based on
provided date time.
But nonetheless it seems like if the revision date range functionality is
going to be there it should work?
Thanks
On Feb 24, 2017 5:24 PM, "Eric Johnson" wrote:
That's an interesting one.
I don't know why you're seeing the behavior you're seeing. However, I can
tell you that relying on the date is probably a mistake. Instead, better to
capture the revision # for the repository, and log for revision #s after
the last one you got. There are scenarios in which the svn:date information
recorded with a revision need not appear in strict chronological order.
I've run into this after combining repositories with svn:load.
Also it is possible to either change an svn:date property (svnadmin propset
...), or remove it altogether. In other words, depending on what you allow
of the repository clients, the date is not a reliable indicator of "changed
since".
Eric.
On Fri, Feb 24, 2017 at 10:08 AM, Dane Kantner
wrote:
> I'm running a script on a scheduled basis where each new iteration I'm
> essentially checking against a newer time from the last check-in, so if the
> last check-in was at 2017-02-23T18:51:15.175583Z the goal would be to add
> ticks to that after that in terms of the revision to retrieve everything
> after that last check-in time via the svn log command. Generally this is
> working great, but the actual results from the command aren't always
> consistent. Sometimes the return results will include stuff that's
> obviously before the provided start date. I initially was adding ticks,
> then I added a second, and now even in the below command I'm getting
> inconsistent results whereby it's returning something that's a full 20
> minutes before the command inputted... So I'm at a loss--is this a parsing
> error, is this date not really compliant (I believe it is...), etc.? I've
> tried consolidating the date format to just 2017-02-23T18:52Z etc as well
> and it doesn't matter.
>
> The exactly command (slightly redacted here) I'm running is:
>
> svn.exe log --non-interactive --trust-server-cert --username ""
> --password "*" --revision
> "{2017-02-23T18:51:17Z}:{2017-02-24T02:46:15.225107Z}"
> --verbose --xml
> "https://AsXXX.4X.nett:443/svn/asi/br/synergyR1.48";
> "DOTNET/A/ExternalComponents" "DOTNET/A/Sequencer" "DOTNET/A/Synergy"
>
>
> and the resultant XML is:
> returning two items within that, the first of which should be there and
> one which is before the provided time:
>
>
>
>
>
> revision="54437">
> oooy
> 2017-02-23T18:51:15.175583Z
>
> action="M"
>prop-mods="true"
>text-mods="false"
>kind="dir">/branches/SynergyR1.48/DOTNET/A/Synergy
> ...
> revision="54442">
> oooyb
> 2017-02-24T02:46:15.225107Z
>
>
> I've been manually running this command from windows on multiple machines
> w/ same result. I have latest tortoise client on at least 2 of the machines
> but SVN server itself is version 1.8.11r1643975. I don't see anything too
> obvious in the change log since that seems relevant to this though if it
> were a bug.
>
> So the time is 2017-02-23T18:51:15.175583Z ... I've tried changing the
> start time and the very specific point in start time at which it goes from
> including it here is {2017-02-23T19:06:02.41247Z} changing it one tick up
> to: {2017-02-23T19:06:02.41248Z} ... That's roughly shy of exactly 15
> minutes after the actual checked time time. What is going on here w/ this
> parsing? Again to clarify though even the simpler format
> {2017-02-23T18:53Z} fails to properly parse as that includes the check-in
> when it shouldn't. I've also tried a simple end date/time and that doesn't
> affect the results.
>
>
> Anyone have any suggestions or what to try to track this down? Given the
> time
>
