Re: How to prevent casual browsing
On 1/1/14, 11:55 AM, Peter Flynn wrote: > Apparently so; and this appears to be new (recent) behaviour. Quite why svn > believes it needs to check the permissions one level above where it was told > to > go is unclear to me, but I'm sure wiser heads have thought this one through. This is actually really old behavior. > OT but I can't see why the REPORT request didn't need authentication; but it's > moot anyway. Because the LimitExcept included REPORT. > At that point it would seem that it ought ask my client to authenticate, and > it > would prompt me for the credentials. Agreed, I've started working on fixing that, but found there are an awful lot of places where it needs fixing. So I haven't finished yet. We have a long standing history of not necessarily returning the proper HTTP result code. > I am unclear on the distinction between /etc/svn.authz and /etc/svn.auth here. > The filename I am using for AuthUserFile is /etc/svn-auth-file; I don't have > any other svn file in /etc. /etc/svn.auth was the username/password map for Basic authentication. Doesn't matter what you call it. >> Technically you don't need the AuthzSVNAccessFile either, > > In fact it doesn't work with it at all; I get > >>> $ svn up >>> Updating '.': >>> svn: E175013: Unable to connect to a repository at URL >>> 'http://xxx.xxx.xx/svn/y' >>> svn: E175013: Access to 'http://xxx.xxx.xx/svn/y' forbidden > > If I comment out AuthzSVNAccessFile, I still get > >>> $ svn up >>> Updating '.': >>> svn: E22: Not authorized to open root of edit operation > > However, if I also comment out the SVNPathAuthz short_circuit line, it all > works correctly. If you don't remove the LimitExcept block you're going to still have those sorts of problems unless you set "SVNPathAuthz off" which I wouldn't recommend. Once you're removed the LimitExcept block (making your config similar to the config I posted), then you can start potentially removing AuthzSVNAccessFile. > Thank you very much indeed for the comprehensive explanation and a working > solution. Sure.
Repository Structure Question
I'm part of a small development team (currently 4). We have two applications used in-house that consist of about 1900 source files. The two applications share about 1880 of the files in common, and there are only about 20 different between them. For a lot of complicated reasons I won't go into here, we can't split the common files into a shared-library sort of project. Most of our development goes on in application 'A'. Currently we then transferred over to the other application 'B' development machine manually and build/test that one. I was thinking of having all the 'A' files be in the main /application/trunk tree of the repository and then somehow have just the 20 or so files unique to 'B' in some sort of /application/branches/Bapp directory tree. This means I'd have to 'switch' those 20 files, (one time only right?), on the B-development machine so it would be a mix of mostly /trunk and just those few files under /branches/Bapp. This would mean that once changes made on the 'A' system are committed, we could just go to the 'B' machine, do an update, and build. If a change happened to be on one of the 20 files, we would have to 'merge' that change from /trunk over into the /branches/Bapp tree, right?? I think we can live with that. Does this sound like it would work, or is there a better way (short of splitting 1880 files off into some other project)?? Currently the team hasn't used any form of version control on these applications because 'it would be too hard...' I desperately want to get it/them under subversion without making two complete projects. I know subversion won't 'share' files between projects and I understand about that. But I just need a way to deal with these 20 out of 1900 files. (may even be less than that when we start actually digging into it) Thanks for any input. Mike Fochtman P.S. Not subscribed to list, so please cc to my 'from' address.
Re: Repository Structure Question
If you can separate out the twenty files that might be different between the two projects - put them into a different folder for the "A" application as well, and not just for "B" - then your process likely gets even easier. Then you can have the files in "B" be a straight up ongoing branch of what's different from the changes in "A". Create that branch by first making a copy of those 20 files from "A", then replacing them with the versions from B & committing. Eric. On 1/2/14, 2:25 PM, Mike Fochtman wrote: I'm part of a small development team (currently 4). We have two applications used in-house that consist of about 1900 source files. The two applications share about 1880 of the files in common, and there are only about 20 different between them. For a lot of complicated reasons I won't go into here, we can't split the common files into a shared-library sort of project. Most of our development goes on in application 'A'. Currently we then transferred over to the other application 'B' development machine manually and build/test that one. I was thinking of having all the 'A' files be in the main /application/trunk tree of the repository and then somehow have just the 20 or so files unique to 'B' in some sort of /application/branches/Bapp directory tree. This means I'd have to 'switch' those 20 files, (one time only right?), on the B-development machine so it would be a mix of mostly /trunk and just those few files under /branches/Bapp. This would mean that once changes made on the 'A' system are committed, we could just go to the 'B' machine, do an update, and build. If a change happened to be on one of the 20 files, we would have to 'merge' that change from /trunk over into the /branches/Bapp tree, right?? I think we can live with that. Does this sound like it would work, or is there a better way (short of splitting 1880 files off into some other project)?? Currently the team hasn't used any form of version control on these applications because 'it would be too hard...' I desperately want to get it/them under subversion without making two complete projects. I know subversion won't 'share' files between projects and I understand about that. But I just need a way to deal with these 20 out of 1900 files. (may even be less than that when we start actually digging into it) Thanks for any input. Mike Fochtman P.S. Not subscribed to list, so please cc to my 'from' address.
Keyword expansion from merged changes
I've used the Rev keyword in some of our code, and we noticed that there may be a use case gap for the Rev/Revision and possibly Id keyword. As expected the keyword gets updated with any checkin, but there may be a need to have a merge-history aware version these keywords. Meaning that the Rev shown from a merge isn't the actual checkin of the merge, but the change origin of the merge. So the use case would be branching a project P from the trunk to do some work, them merging those changes back. In its current form, the rev takes the revision of the merged checkin rather then the origin of the merged change. We see a need for this capability of having a merge-history aware keyword, and one way to accomplish this without adding yet another keyword would be to have the existing keywords support some kind of argument like options. For example, when setting for the Rev keyword (as it works right now), simply set Rev for the property svn:keywords, but if the user really wanted Rev to indicate the delta origin of the rev they would use rev.g or perhaps rev -g in the svn:keyword entry... The disadvantage with this meathod vs creating either new svn keywords or having the options embedded directly in the keyword referenced within the file is that you cannot have two different revs in the same file. Fuel for though? -Jim
Re: Keyword expansion from merged changes
On 1/2/14, 7:16 PM, James Hanley wrote: > I've used the Rev keyword in some of our code, and we noticed that there may > be > a use case gap for the Rev/Revision and possibly Id keyword. > > As expected the keyword gets updated with any checkin, but there may be a need > to have a merge-history aware version these keywords. Meaning that the Rev > shown from a merge isn't the actual checkin of the merge, but the change > origin > of the merge. > > So the use case would be branching a project P from the trunk to do some work, > them merging those changes back. In its current form, the rev takes the > revision of the merged checkin rather then the origin of the merged change. > > We see a need for this capability of having a merge-history aware keyword, and > one way to accomplish this without adding yet another keyword would be to have > the existing keywords support some kind of argument like options. The ONLY way to uniquely identify a point in history for a path is with the revision for that path (even a timestamp isn't unique since we allow dates that aren't sequential in the repository, yes this breaks using dates with -r). You can't identify the point in history a file is from on a path from the source of the merge because that doesn't account for any preceding differences. Consider a change to /trunk that gets merged to /branches/1.7.x and /branches/1.8.x. If you set the keywords based on the trunk revision that was merged then the changed files in 1.7.x and 1.8.x would show the same keyword info, even though they may be drastically different. You say that "you see a need for this capability" and then immediately launch into ideas for how to implement it. I'd focus on explaining why you see the need for the capability before we get to any discussion about how to implement it.
