Re: Viewing Subversion in 3D (without glasses)

[Pablo Beltran]

That sort of information can be represented in the current 2D Subversion
space as the line between two points:

Example: http://www.svnflash.com/images/svnflash/branch_is_2d.png

If the */a/b* item at the *N+2* revision is replaced (could be also copied
or merged) with the previous content of the */a/c* item that produces a line
on the same plane surface:

*/a/c@(N+1)->/a/b@(N+2)*

In general, any information which can be represented as a group of points of
type *p...@revision* can be represented as a curve belonging to a 2D plane
surface.

In other words:   (path, revision) is a vector on the 2D space. So a 3rd
coordinate/concept (path, revision, ?) should  be needed in order to get a
3D space.


On Tue, Jan 11, 2011 at 4:47 AM, Nick  wrote:

> On Mon, 2011-01-10 at 18:46 +0100, Pablo Beltran wrote:
> > Hi,
> >
> > Subversion tracks the evolution of a tree structure along the time.
> > Changes can be represented in a bi-dimensional system coordinates:
> > time vs space.
> >
> > The vertical coordinate (space) is the path of the items of the tree
> > structure and the horizontal coordinate (time) is the revision number.
> >
> > Example: http://www.svnflash.com/images/svnflash/subversion_3d.png
> >
> > Changes of the tree structure along the time can be represented as
> > dots (red in the example)  in that system coordinates.
> >
> > Has some sense adding a 3rd coordinate meaning something unknown for
> > me at the present?
> >
> > Thanks and sorry for so abstract question.
>
> What about using the 3rd axis to show branches and/or merges?
>
> Nick
>
>
>

Re: annotate/log mergeinfo

[JamieEchlin]

Kylo Ginsberg-2 wrote:
> 
> Does anyone have a script that will annotate and/or log mergeinfo.  I.e.
> I'd
> like to:
> * see all the log entries that modified svn:mergeinfo for a given node
> (file
> or directory)
> * annotate the svn:mergeinfo for a given node, so I can see what
> author/rev
> was responsible for each line
> 

As far as I know "svn log --with-revprop svn:mergeinfo --xml ." should do
that but doesn't.

Therefore you need to write a script to walk the log entries on the branch,
and compare with the predecessor. I think here are a few of these about, but
I wrote my own,  http://old.nabble.com/file/p30642064/ShowRevProps.groovy
ShowRevProps.groovy ... maybe this will help you.

jamie
-- 
View this message in context: 
http://old.nabble.com/annotate-log-mergeinfo-tp30638936p30642064.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: usage of svn_wc_diff

[JamieEchlin]

Daniel Näslund wrote:
> 
> Hope, you'll be able to solve your problem. Here's a script that's a bit
> more clean than the previous one. I haven't tested it much at all but it
> appears to be able to display added, modified and deleted properties set
> on both dirs and files. The '###' lines represents TODO's.
> 

If anyone else uses this code, I'd just thought I'd mention belatedly that
you don't need a write lock to do the diff. So pass False to adm_open3.
Doing this speeds up execution by 12s on a working copy hosted on an NTFS
volume.

BTW, it seems svn and NTFS don't play nice:
http://superuser.com/questions/15192/bad-ntfs-performance, and this is easy
to demonstrate by comparing the lock/unlock performance on NTFS against a
FAT-formatted disk. Do the new format working copies in 1.7 fix this?

cheers, jamie
-- 
View this message in context: 
http://old.nabble.com/usage-of-svn_wc_diff-tp30399137p30642926.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: How to get svn-bisect?

[Les Mikesell]

On 1/11/11 1:09 AM, Ryan Schmidt wrote:

On Jan 10, 2011, at 13:39, Tech Geek wrote:


We are using svn, version 1.6.12 (r955767) on a Linux based machine (SVN 
Server) and use TortoiseSVN as clients. However, I do not see command 
svn-bisect on both of them. How can I get svn-bisect just like there is 
git-bisect?


Subversion does not include a program called "svn-bisect". For those of us not 
familiar with git, perhaps you could explain what git-bisect does, then we can tell you 
if there is equivalent functionality available in Subversion.

Alternately, a Google search shows me others have written tools called 
"svn-bisect" which may do what you want:

http://www.google.com/search?q=svn-bisect


I read a few of the links out of curiosity - this one expains what it does and 
why you would want it:

http://blogs.atlassian.com/developer/2009/01/git_bisect.html

Basically you give it a good and bad revision and a test to run and it finds the 
commit that broke things with a binary search.  Of course if you were using 
something like Hudson doing continuous builds for you, you'd already know...


--
  Les Mikesell
   lesmikes...@gmail.com

Re: How to get svn-bisect?

[Ryan Schmidt]

On Jan 11, 2011, at 07:42, Les Mikesell wrote:
> On 1/11/11 1:09 AM, Ryan Schmidt wrote:
>> Subversion does not include a program called "svn-bisect". For those of us 
>> not familiar with git, perhaps you could explain what git-bisect does, then 
>> we can tell you if there is equivalent functionality available in Subversion.
>> 
>> Alternately, a Google search shows me others have written tools called 
>> "svn-bisect" which may do what you want:
>> 
>> http://www.google.com/search?q=svn-bisect
>> 
> 
> I read a few of the links out of curiosity - this one expains what it does 
> and why you would want it:
> http://blogs.atlassian.com/developer/2009/01/git_bisect.html
> 
> Basically you give it a good and bad revision and a test to run and it finds 
> the commit that broke things with a binary search.  Of course if you were 
> using something like Hudson doing continuous builds for you, you'd already 
> know...

Yup, that's what I figured it would do.

A couple days ago I manually bisected a problem in an open source project I've 
been involved with. There is no test suite, and I supposed it would have taken 
me longer to figure out how to write a test for the problem "the entire window 
is purple" than to just manually build and run a few revisions. In the end, the 
revision I identified unfortunately changed at least a dozen things in the code 
-- including refactoring existing code, adding new code, and even whitespace 
changes (groan) -- so that hasn't been totally helpful in tracking down the 
problem yet. Let it be yet another repeat of the lesson to commit the smallest 
unit of work possible. It's not like the repository is going to run out of 
revisions! :)

Re: Is there a 2 GB file size limit in Subversion - Apache? 413 Request Entity Too Large -- Solution

[kmradke]

"Curley, John"  wrote on 01/11/2011 12:03:46 
AM:
> There seems to be a 2 GB file size limit, if you use the default 
> command to commit. We encountered this problem and eventually found 
> the solution.
> 
> This is not a Subversion limit, nor is it an Apache limit.

I believe this is only a limit on windows platforms.  The ra_neon
layer appears to be sending a negative size value in the http header.
Possibly a missing cast in the code.  I never was able to debug
it further.  As you found, using ra_serf (or using ra_neon on most
unix platforms) should work fine.  I've seen 20GB+ commits work.

(It appears the actual limit is the size of the compressed delta of
an individual file needs to be less than 2GB.)

> The default module for accessing the repository is ra_neon. This 
> module (!) has the 2 GB limit. If you specify using ra_serf (serf) 
> instead, that works.
> 
> This is the command line option (from the client):  --config-option 
> servers:global:http-library=serf
> 
> I don't know how to do this in a GUI situation. It took me a LONG 
> time to find this on the web.

You can configure the servers file to specify the use of ra_neon:
(This would actually default all clients to use serf)

http-library=serf


Kevin R.

RE: svnadmin create and not being method agnostic

[Bob Archer]

> > svnadmin create .\repository
> > svnserve -r .
> >
> > and a repository is created and served via svnserve. With the
> above
> > defaults, a third step is required, which can get tedious. I'd
> propose
> > enabling svnserve by default, and it can then be disabled if
> required. This
> > also maintains the ease of creating test scripts to try and
> reproduce
> > issues.
> 
> It's *too* easy. Since the default svnserve.conf is very
> permissive,
> and because default svnserve is on an unprivileged port so any user
> can serve anyone else's "readable" repository to outside access,
> without the original author's knowledge or explicit consent. The
> default permissions of "svnadmin create" and "svnadmin hotcopy" are
> much too permissive, and the concatenation of separate "the admin
> should set these if they want" options creates a quite noticeable
> security risk.

Yes, well aren't you still only keeping the honest people honest? Since svn is 
open source anyone can edit the code so the check of servers.conf is a no-op 
and it serves anyway. 

Why are you making your repository "readable" in the first place?

BOb

Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[NN Ott]

>
>
> >> To recap, as Les put it:
> >>
> >> I think the idea is that he'd like to see the development history of
> both the vendor and local changes as a continuous set of changes as you
> would if they were in the same repository with log and diff working across
> any points in time or branch versions.  It seems like a reasonable thing to
> want, but I don't think it is possible with subversion.
> >
> >
>
> I don't think the request can be met by Subversion. Subversion is a
> centralized version control system; the request is met by not using a
> centralized version control system, but instead using a distributed version
> control system.
>
>
>

With the new merge tracking capability being added, I would think this could
be on the horizon as well.  A full fledged distributed system hardly is
needed or even what I am looking for.

Has such a feature request already been logged?

Can I commit under a different user name?

[NN Ott]

Hi all,

If UserA checks out a working copy on to his machine, can UserB walk up to
that machine and the commit changes under his own credentials?

Would seem possible, but just wanted to double check if there are any pit
falls.

Thanks

Re: Can I commit under a different user name?

[Andy Levy]

On Tue, Jan 11, 2011 at 12:42, NN Ott  wrote:
> Hi all,
> If UserA checks out a working copy on to his machine, can UserB walk up to
> that machine and the commit changes under his own credentials?
> Would seem possible, but just wanted to double check if there are any pit
> falls.
> Thanks

Credentials are cached in the user's home directory (~/.subversion,
%APPDATA%\subversion), not in the working copy. If the 2 users have
separate logins on the machine, then it's real easy. Otherwise, you
can pass --username and --password command-line options.

But I'd advise against encouraging this practice. In this scheme,
UserA can make changes, and they'll be attributed to UserB in
Subversion. A malicious UserA could cause a lot of trouble for UserB
here.

Re: Can I commit under a different user name?

[David Weintraub]

On Tue, Jan 11, 2011 at 12:42 PM, NN Ott  wrote:

> Hi all,
>
> If UserA checks out a working copy on to his machine, can UserB walk up to
> that machine and the commit changes under his own credentials?
>
> Would seem possible, but just wanted to double check if there are any pit
> falls.
>


You can always create a repository and run your own tests. That's what I
just did. No issues with committing as another user.

However, I'm not sure whether you'd want to encourage the practice or not.
User B could have easily committed the work as User A which would be closer
to the truth. I'm assuming something like this would come up if User A left,
and someone has to check in the work User A did.

-- 
David Weintraub
qazw...@gmail.com

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[Stefan Sperling]

On Tue, Jan 11, 2011 at 12:36:58PM -0500, NN Ott wrote:
> >
> >
> > >> To recap, as Les put it:
> > >>
> > >> I think the idea is that he'd like to see the development history of
> > both the vendor and local changes as a continuous set of changes as you
> > would if they were in the same repository with log and diff working across
> > any points in time or branch versions.  It seems like a reasonable thing to
> > want, but I don't think it is possible with subversion.
> > >
> > >
> >
> > I don't think the request can be met by Subversion. Subversion is a
> > centralized version control system; the request is met by not using a
> > centralized version control system, but instead using a distributed version
> > control system.
> >
> >
> >
> 
> With the new merge tracking capability being added, I would think this could
> be on the horizon as well.  A full fledged distributed system hardly is
> needed or even what I am looking for.

Merge tracking has nothing to do with this feature request.
 
> Has such a feature request already been logged?

No, and there is no point in logging it.

The basic concept of a centralized version control system is that a
repository is a single universe. Changes only "happen" in that universe
and you cannot (easily) move or replay changes between universes without
losing the unique identifier the change had in its original universe.

There are some ways of merging repositories, but those require admin access
to the server and are generally not considered normal use cases.
See here: http://subversion.apache.org/faq.html#multi-merge

It sounds like what you really want is commit access to the upstream
Subversion repository, possibly restricted to a special branch.
Then your change identifiers would be in the same universe.

Stefan

Re: Can I commit under a different user name?

[NN Ott]

On Tue, Jan 11, 2011 at 12:50 PM, Andy Levy  wrote:

> On Tue, Jan 11, 2011 at 12:42, NN Ott  wrote:
> > Hi all,
> > If UserA checks out a working copy on to his machine, can UserB walk up
> to
> > that machine and the commit changes under his own credentials?
> > Would seem possible, but just wanted to double check if there are any pit
> > falls.
> > Thanks
>
> Credentials are cached in the user's home directory (~/.subversion,
> %APPDATA%\subversion), not in the working copy. If the 2 users have
> separate logins on the machine, then it's real easy. Otherwise, you
> can pass --username and --password command-line options.
>
> But I'd advise against encouraging this practice. In this scheme,
> UserA can make changes, and they'll be attributed to UserB in
> Subversion. A malicious UserA could cause a lot of trouble for UserB
> here.
>


Ok, thank you.  Yeah this is not intended as a standard workflow.  :)

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[NN Ott]

On Tue, Jan 11, 2011 at 1:02 PM, Stefan Sperling  wrote:

> On Tue, Jan 11, 2011 at 12:36:58PM -0500, NN Ott wrote:
> > >
> > >
> > > >> To recap, as Les put it:
> > > >>
> > > >> I think the idea is that he'd like to see the development history of
> > > both the vendor and local changes as a continuous set of changes as you
> > > would if they were in the same repository with log and diff working
> across
> > > any points in time or branch versions.  It seems like a reasonable
> thing to
> > > want, but I don't think it is possible with subversion.
> > > >
> > > >
> > >
> > > I don't think the request can be met by Subversion. Subversion is a
> > > centralized version control system; the request is met by not using a
> > > centralized version control system, but instead using a distributed
> version
> > > control system.
> > >
> > >
> > >
> >
> > With the new merge tracking capability being added, I would think this
> could
> > be on the horizon as well.  A full fledged distributed system hardly is
> > needed or even what I am looking for.
>
> Merge tracking has nothing to do with this feature request.
>
> > Has such a feature request already been logged?
>
> No, and there is no point in logging it.
>
> The basic concept of a centralized version control system is that a
> repository is a single universe. Changes only "happen" in that universe
> and you cannot (easily) move or replay changes between universes without
> losing the unique identifier the change had in its original universe.
>
>
> It sounds like what you really want is commit access to the upstream
> Subversion repository, possibly restricted to a special branch.
> Then your change identifiers would be in the same universe.
>
>

I just want the svn copy/log/diff/merge logic to see past, and account for,
and svn:external barrier.   Very much a one-way flow of changes.  Imho,
doesn't seem too bizzare or non-svn like.

How is the external svn rev number + repo info not enough to enable the sort
of local tracking of copy+merge this would require?

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[Daniel Shahaf]

Stefan Sperling wrote on Tue, Jan 11, 2011 at 19:02:00 +0100:
> See here: http://subversion.apache.org/faq.html#multi-merge

This contains a broken link to 
.

Re: Can I commit under a different user name?

[Kylo Ginsberg]

On Tue, Jan 11, 2011 at 9:50 AM, Andy Levy  wrote:

> On Tue, Jan 11, 2011 at 12:42, NN Ott  wrote:
> > Hi all,
> > If UserA checks out a working copy on to his machine, can UserB walk up
> to
> > that machine and the commit changes under his own credentials?
> > Would seem possible, but just wanted to double check if there are any pit
> > falls.
> > Thanks
>
> Credentials are cached in the user's home directory (~/.subversion,
> %APPDATA%\subversion), not in the working copy. If the 2 users have
> separate logins on the machine, then it's real easy. Otherwise, you
> can pass --username and --password command-line options.
>
> But I'd advise against encouraging this practice. In this scheme,
> UserA can make changes, and they'll be attributed to UserB in
> Subversion. A malicious UserA could cause a lot of trouble for UserB
> here.
>

FWIW I manually specify --username/--password all the time (needed for some
of our build scenarios) but I always specify --no-auth-cache to avoid
polluting the credentials cache for future users.

Kylo

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[Stefan Sperling]

On Tue, Jan 11, 2011 at 01:36:37PM -0500, NN Ott wrote:
> I just want the svn copy/log/diff/merge logic to see past, and account for,
> and svn:external barrier.   Very much a one-way flow of changes.  Imho,
> doesn't seem too bizzare or non-svn like.

It may seem like that on the surface.

But an external is a nested checkout within another working copy.
That's all there is to it. It is bound to the repository it came from.

Creating diffs between two distinct Subversion repositories, for
instance, is impossible to achieve with the current design of Subversion.
If you try it, you get an error like this:
svn: 'https://svn.example.com/repos1/README' isn't in the same repository
  as 'https://svn.example.com/repos2/README'

Making this work would require redesign of the system.
It's not an implementation bug that this doesn't work.
It's something the design doesn't support, because Subversion is centralized.

If you want to reason and argue about this you will need to understand
technical details of the current design. So I'd suggest that you familiarize
yourself with Subversion's design, and then rephrase your proposal in a
way that explains how Subversion's current design would need to be
changed in order to achieve what you want.

Unfortunately it's not easy to summarize everything you need to know
in one email.

You'll need to understand how the repository filesystem works.
A fairly good explanation is given here:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history

A good overview of how the client/server communication is currently
structured is given here:
http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html
While linking to the above, it should also be noted that there is a new,
currently unused, interface trying to address various shortcomings:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_editor.h

Stefan

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[Les Mikesell]

On 1/11/2011 12:36 PM, NN Ott wrote:



It sounds like what you really want is commit access to the upstream
Subversion repository, possibly restricted to a special branch.
Then your change identifiers would be in the same universe.



I just want the svn copy/log/diff/merge logic to see past, and account
for, and svn:external barrier.   Very much a one-way flow of changes.


If the changes are really one-way, they'd all be coming from the 
upstream repository.  If you make changes in 2 places, that's a 
distributed system - even if your copy is never pushed back upstream.



  Imho, doesn't seem too bizzare or non-svn like.


The svn way is to get write access to a branch in the one-and-only 
repository if you also want to make changes that are tracked.  Or 
reproduce the upstream commits in your copy letting the revision numbers 
(and any external tracking references) get out of sync.


--
  Les Mikesell
   lesmikes...@gmail.com

RE: including a banner in Subversion URL

[Ramesh Nadupalli]

Thanks Ryan. I am an administrator,  wants to use this feature to notify
users about the upcoming outages, repository movements etc... 

Any pointers? 

-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
Sent: Tuesday, January 11, 2011 2:07 AM
To: Ramesh Nadupalli
Cc: users@subversion.apache.org
Subject: Re: inlcuding a banner in Subversion URL


On Jan 10, 2011, at 20:38, Ramesh Nadupalli wrote:

> I would like to have banner set for a subversion URL, can someone guide
how this can be accomplished?

Do you mean that you would like to customize the way that Subversion
displays pages when someone access a repository's URL in a web browser? If
so, you can do that by providing custom XSLT and CSS files. Use the
directive "SVNIndexXSLT /path/to/svnindex.xsl" in your httpd.conf. Sample
XSLT and CSS files are provided as part of the Subversion source
distribution, or here:

http://svn.apache.org/repos/asf/subversion/trunk/tools/xslt/

Re: including a banner in Subversion URL

[Ryan Schmidt]

On Jan 11, 2011, at 14:34, Ramesh Nadupalli wrote:

> Ryan Schmidt wrote:

> 
>> On Jan 10, 2011, at 20:38, Ramesh Nadupalli wrote:
>> 
>>> I would like to have banner set for a subversion URL, can someone guide
>>> how this can be accomplished?
>> 
>> Do you mean that you would like to customize the way that Subversion
>> displays pages when someone access a repository's URL in a web browser? If
>> so, you can do that by providing custom XSLT and CSS files. Use the
>> directive "SVNIndexXSLT /path/to/svnindex.xsl" in your httpd.conf. Sample
>> XSLT and CSS files are provided as part of the Subversion source
>> distribution, or here:
>> 
>> http://svn.apache.org/repos/asf/subversion/trunk/tools/xslt/
> 
> Thanks Ryan. I am an administrator,  wants to use this feature to notify
> users about the upcoming outages, repository movements etc... 
> 
> Any pointers? 

You can certainly do that -- supply a custom XSLT file as explained above, put 
your messages into that file. Users will see them when they visit the 
repository URL in a web browser.

Of course, users don't usually access a repository URL in a web browser; they 
usually do so in a Subversion client. I don't know of any way to supply a 
custom message to someone using a Subversion client.

And of course the above only works if you're serving your repository with 
Apache. If you're serving it with svnserve, then I have no solution for that 
either.

Re: I can not browsing a subversion webpage

[Daniela Rivas]

Ryan Schmidt wrote:

On Jan 10, 2011, at 10:35, Andy Levy wrote:
  

On Mon, Jan 10, 2011 at 11:20, Daniela Rivas wrote:


I am installing and configuring a subversion repository and I have some
problems doing that.
When I am trying to see the page in a browser, I get the directories trunk,
branches, tags; so I don't get the index.html file that i have inside trunk.
  

If I understand you correctly, you're expecting index.html to be
served to your browser when you browse to the directory containing it?

You're not supposed to. The Subversion repository browser is not
intended to allow you to serve files directly as a website, and
depending on your web content it won't work at all. If you need to
serve a website using the contents of a repository, see
http://subversion.apache.org/faq.html#website-auto-update .



The website auto-update FAQ is good to read, and is indeed necessary if your 
web site is composed of scripts (in PHP, ASP, Java, Python, Ruby, Perl, etc.) 
that need to be processed by the server. However, if your web site is just 
pre-generated HTML, created by hand or in a graphical web site editor (like 
DreamWeaver, RapidWeaver, GoLive, iWeb, etc.) then there's no reason why 
Subversion can't serve it up for you. You wouldn't want to do so for a 
production web site as it would be very slow, but for development purposes, it 
can be fine.

You just need to make sure you set the correct MIME type on everything you add to the repository. You do this 
by setting the svn:mime-type property. Each .html file needs to have the MIME type "text/html"; 
each PNG image should have the MIME type "image/png", and so on. You can, for example, use 
"svn propset svn:mime-type text/html index.html" to set the MIME type of the index.html file.

You should set up auto-props in your Subversion config file so new files you 
add automatically get these properties, but this only applies to new files; for 
your existing files, you'll either have to go through and set the MIME type of 
each by hand, or there exists a script you can use to apply your current 
auto-props rules to your existing files.
  


Hi,

After I have done a svn commit command in a working copy, how can i do 
to update the repository or that it is not supposed to happen? Because 
when I tried to browser it after that i see the same page i had before.



Thanks

Re: I can not browsing a subversion webpage

[Les Mikesell]

On 1/11/2011 3:16 PM, Daniela Rivas wrote:




You just need to make sure you set the correct MIME type on everything
you add to the repository. You do this by setting the svn:mime-type
property. Each .html file needs to have the MIME type "text/html";
each PNG image should have the MIME type "image/png", and so on. You
can, for example, use "svn propset svn:mime-type text/html index.html"
to set the MIME type of the index.html file.

You should set up auto-props in your Subversion config file so new
files you add automatically get these properties, but this only
applies to new files; for your existing files, you'll either have to
go through and set the MIME type of each by hand, or there exists a
script you can use to apply your current auto-props rules to your
existing files.


Hi,

After I have done a svn commit command in a working copy, how can i do
to update the repository or that it is not supposed to happen? Because
when I tried to browser it after that i see the same page i had before.


If you are looking at a directory like /trunk, you should see the 
revision number update after a commit.  If not, maybe the browser is not 
updating its cached page.  If you want to see the versioning better 
through a browser you could install viewvc.


--
  Les Mikesell
   lesmikes...@gmail.com

OPTIONS of ... could not connect to server

[Ben Kim]

Hi 

Whenever I commit, I'm getting this message.

svn: Commit failed (details follow):
svn: OPTIONS of 'https://svn.example.com/repos/mysite': could not connect to 
server (https://svn.example.com)


Can anyone tell me where to look? Thanks.



I'm on CentOS 5.4, kernel 2.6.18-128.el5 #1 SMP

svn, version 1.6.12 (r955767) compiled Jun 22 2010, 11:47:19
neon-0.25.5-10.el5_4.1
neon-devel-0.25.5-10.el5_4.1




-- 
Ben Kim
Lead Database Administrator
College of Education
Texas A&M University
http://benix.tamu.edu

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[NN Ott]

On Tue, Jan 11, 2011 at 2:16 PM, Stefan Sperling  wrote:

> On Tue, Jan 11, 2011 at 01:36:37PM -0500, NN Ott wrote:
> > I just want the svn copy/log/diff/merge logic to see past, and account
> for,
> > and svn:external barrier.   Very much a one-way flow of changes.  Imho,
> > doesn't seem too bizzare or non-svn like.
>
> It may seem like that on the surface.
>
> But an external is a nested checkout within another working copy.
> That's all there is to it. It is bound to the repository it came from.
>
> Creating diffs between two distinct Subversion repositories, for
> instance, is impossible to achieve with the current design of Subversion.
> If you try it, you get an error like this:
> svn: 'https://svn.example.com/repos1/README' isn't in the same repository
>  as 'https://svn.example.com/repos2/README'
>
> Making this work would require redesign of the system.
> It's not an implementation bug that this doesn't work.
> It's something the design doesn't support, because Subversion is
> centralized.
>
> If you want to reason and argue about this you will need to understand
> technical details of the current design. So I'd suggest that you
> familiarize
> yourself with Subversion's design, and then rephrase your proposal in a
> way that explains how Subversion's current design would need to be
> changed in order to achieve what you want.
>
> Unfortunately it's not easy to summarize everything you need to know
> in one email.
>
> You'll need to understand how the repository filesystem works.
> A fairly good explanation is given here:
>
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history
>
> A good overview of how the client/server communication is currently
> structured is given here:
> http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html
> While linking to the above, it should also be noted that there is a new,
> currently unused, interface trying to address various shortcomings:
>
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_editor.h
>
> Stefan
>

Thank you for explaining, Stefan.  I'll check those links out.   As you say,
my assumptions are based more on mis-understanding than anything else.

Re: Feature Request: [Was: Best way to maintain patches to a 3rd party library?]

[Johan Corveleyn]

On Tue, Jan 11, 2011 at 11:09 PM, NN Ott  wrote:
>
>
> On Tue, Jan 11, 2011 at 2:16 PM, Stefan Sperling  wrote:
>>
>> On Tue, Jan 11, 2011 at 01:36:37PM -0500, NN Ott wrote:
>> > I just want the svn copy/log/diff/merge logic to see past, and account
>> > for,
>> > and svn:external barrier.   Very much a one-way flow of changes.  Imho,
>> > doesn't seem too bizzare or non-svn like.
>>
>> It may seem like that on the surface.
>>
>> But an external is a nested checkout within another working copy.
>> That's all there is to it. It is bound to the repository it came from.
>>
>> Creating diffs between two distinct Subversion repositories, for
>> instance, is impossible to achieve with the current design of Subversion.
>> If you try it, you get an error like this:
>> svn: 'https://svn.example.com/repos1/README' isn't in the same repository
>>  as 'https://svn.example.com/repos2/README'
>>
>> Making this work would require redesign of the system.
>> It's not an implementation bug that this doesn't work.
>> It's something the design doesn't support, because Subversion is
>> centralized.
>>
>> If you want to reason and argue about this you will need to understand
>> technical details of the current design. So I'd suggest that you
>> familiarize
>> yourself with Subversion's design, and then rephrase your proposal in a
>> way that explains how Subversion's current design would need to be
>> changed in order to achieve what you want.
>>
>> Unfortunately it's not easy to summarize everything you need to know
>> in one email.
>>
>> You'll need to understand how the repository filesystem works.
>> A fairly good explanation is given here:
>>
>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history
>>
>> A good overview of how the client/server communication is currently
>> structured is given here:
>> http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html
>> While linking to the above, it should also be noted that there is a new,
>> currently unused, interface trying to address various shortcomings:
>>
>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_editor.h
>>
>> Stefan
>
> Thank you for explaining, Stefan.  I'll check those links out.   As you say,
> my assumptions are based more on mis-understanding than anything else.

This discussion just triggered my memory: a while ago I read in a
thread on the users list something about "foreign repository merges".
Don't know if that's something that could be useful to you, but who
knows ... See:

http://svn.haxx.se/users/archive-2010-02/0223.shtml

The thread concludes with "Don't tell anybody", so I'm not sure I'm
supposed to do just that ;-).

Cheers,
-- 
Johan

RE: including a banner in Subversion URL

[Ramesh Nadupalli]

Thanks Ryan. Will give a shot. 

-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] 
Sent: Tuesday, January 11, 2011 3:39 PM
To: Ramesh Nadupalli
Cc: users@subversion.apache.org
Subject: Re: including a banner in Subversion URL

On Jan 11, 2011, at 14:34, Ramesh Nadupalli wrote:

> Ryan Schmidt wrote:

> 
>> On Jan 10, 2011, at 20:38, Ramesh Nadupalli wrote:
>> 
>>> I would like to have banner set for a subversion URL, can someone 
>>> guide how this can be accomplished?
>> 
>> Do you mean that you would like to customize the way that Subversion 
>> displays pages when someone access a repository's URL in a web 
>> browser? If so, you can do that by providing custom XSLT and CSS 
>> files. Use the directive "SVNIndexXSLT /path/to/svnindex.xsl" in your 
>> httpd.conf. Sample XSLT and CSS files are provided as part of the 
>> Subversion source distribution, or here:
>> 
>> http://svn.apache.org/repos/asf/subversion/trunk/tools/xslt/
> 
> Thanks Ryan. I am an administrator,  wants to use this feature to 
> notify users about the upcoming outages, repository movements etc...
> 
> Any pointers? 

You can certainly do that -- supply a custom XSLT file as explained above,
put your messages into that file. Users will see them when they visit the
repository URL in a web browser.

Of course, users don't usually access a repository URL in a web browser;
they usually do so in a Subversion client. I don't know of any way to supply
a custom message to someone using a Subversion client.

And of course the above only works if you're serving your repository with
Apache. If you're serving it with svnserve, then I have no solution for that
either.

SVN Hooks to require log message, limit size and file type

[David Xie]

Hello,

I am looking for a hook to require log message when commit. I succeded to do
it.

At the same time, I want to limit size less than 10MB and forbid .zip .7z
.rar file type.
I found some hooks from internet, tried multi times but all failed. I could
always commit big than 10M files and zip files. I struggled two days but
could not resolve it.

I post my pre-commit at the end.
RHEL 5.3
SVN 1.6.15
Apache 2.2.14
Java 1.6.0_17

Would someone give me some help? Great thanks!

Regards,
David

pre-commit :
#!/bin/sh
REPOS="$1"
TXN="$2"
MAX_SIZE=1024
MIN_LOG=10
FILTER='\.(zip|rar|o|obj|tar|gz)$'
SVNLOOK=/local/svnroot/subversion/bin/svnlook
# Make sure that the log message contains some text.
LOGMSG=$($SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c)
if [ "$LOGMSG" -lt $MIN_LOG ]
then
echo -e "Please enter at least 10 characters for log message. Questions,
contact David" >&2
exit 1
fi

files=$($SVNLOOK changed -t $TXN $REPOS |awk '{print $2}')
for f in $files
do

#check file type
if echo $f|tr A-Z a-z|grep -Eq $FILTER
then
echo "File $f is not allow ($FILTER) file" >&2
exit 1
fi

#check file size
filesize=$($SVNLOOK cat -t $TXN $REPOS $f|wc -c)
if [ "$filesize" -gt "$MAX_SIZE"]
then
echo "File $f is too large(must <=$MAX_SIZE)" >&2
exit 1
fi

done

#All checks passed, so allow the commit.
exit 0

Re: including a banner in Subversion URL

[Daniel Shahaf]

Ryan Schmidt wrote on Tue, Jan 11, 2011 at 14:38:36 -0600:
> On Jan 11, 2011, at 14:34, Ramesh Nadupalli wrote:
> 
> > Ryan Schmidt wrote:
> 
> > 
> >> On Jan 10, 2011, at 20:38, Ramesh Nadupalli wrote:
> >> 
> >>> I would like to have banner set for a subversion URL, can someone guide
> >>> how this can be accomplished?
> >> 
> >> Do you mean that you would like to customize the way that Subversion
> >> displays pages when someone access a repository's URL in a web browser? If
> >> so, you can do that by providing custom XSLT and CSS files. Use the
> >> directive "SVNIndexXSLT /path/to/svnindex.xsl" in your httpd.conf. Sample
> >> XSLT and CSS files are provided as part of the Subversion source
> >> distribution, or here:
> >> 
> >> http://svn.apache.org/repos/asf/subversion/trunk/tools/xslt/
> > 
> > Thanks Ryan. I am an administrator,  wants to use this feature to notify
> > users about the upcoming outages, repository movements etc... 
> > 
> > Any pointers? 
> 
> You can certainly do that -- supply a custom XSLT file as explained above, 
> put your messages into that file. Users will see them when they visit the 
> repository URL in a web browser.
> 
> Of course, users don't usually access a repository URL in a web
> browser; they usually do so in a Subversion client. I don't know of
> any way to supply a custom message to someone using a Subversion
> client.
> 

Changing the authentication realm will have the right effect... (for
read-protected repositories)

> And of course the above only works if you're serving your repository with 
> Apache. If you're serving it with svnserve, then I have no solution for that 
> either.
> 
> 
> 

Re: SVN Hooks to require log message, limit size and file type

[Daniel Becroft]

On Wed, Jan 12, 2011 at 11:46 AM, David Xie  wrote:

> Hello,
>
> I am looking for a hook to require log message when commit. I succeded to
> do it.
>
> At the same time, I want to limit size less than 10MB and forbid .zip .7z
> .rar file type.
> I found some hooks from internet, tried multi times but all failed. I could
> always commit big than 10M files and zip files. I struggled two days but
> could not resolve it.
>
> I post my pre-commit at the end.
> RHEL 5.3
> SVN 1.6.15
> Apache 2.2.14
> Java 1.6.0_17
>
> Would someone give me some help? Great thanks!
>
> Regards,
> David
>

I'm unfamiliar with unix scripting, but you could try outputting debug
messages to a basic text file, so you can trace it through as it runs.

Cheers,
Daniel B.


> pre-commit :
> #!/bin/sh
> REPOS="$1"
> TXN="$2"
> MAX_SIZE=1024
> MIN_LOG=10
> FILTER='\.(zip|rar|o|obj|tar|gz)$'
> SVNLOOK=/local/svnroot/subversion/bin/svnlook
> # Make sure that the log message contains some text.
> LOGMSG=$($SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c)
> if [ "$LOGMSG" -lt $MIN_LOG ]
> then
> echo -e "Please enter at least 10 characters for log message. Questions,
> contact David" >&2
> exit 1
> fi
>
> files=$($SVNLOOK changed -t $TXN $REPOS |awk '{print $2}')
> for f in $files
> do
>
> #check file type
> if echo $f|tr A-Z a-z|grep -Eq $FILTER
> then
> echo "File $f is not allow ($FILTER) file" >&2
> exit 1
> fi
>
> #check file size
> filesize=$($SVNLOOK cat -t $TXN $REPOS $f|wc -c)
> if [ "$filesize" -gt "$MAX_SIZE"]
> then
> echo "File $f is too large(must <=$MAX_SIZE)" >&2
> exit 1
> fi
>
> done
>
> #All checks passed, so allow the commit.
> exit 0
>
>