RE: Compile/Install Subversion client on AIX

[Giulio Troccoli]

Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447





From: Srivastava, Sumit [mailto:ssrivasta...@cvs.com]
Sent: 05 March 2010 17:15
To: users@subversion.apache.org
Subject: Compile/Install Subversion client on AIX



I have to install Subversion client 1.6.3 on a AIX machine. Is there a 
place I can get the pre compiled binaries and just install it?

Otherwise, where can I find the steps to compile the source code and 
install svn client.

Please help!

Thanks,

Sumit


Please do not post in HTML.

I have successfully built 1.6.9 on AIX 5.3 and 1.4.5 on AIX 4.3 (still working 
on 1.6.9 on AIX 4.3). This is what I did for AIX 5.3 (SVN 1.6.9)

mkdir svnbuild
cd svnbuild
gunzip -c subversion-deps-1.6.9.tar.gz | tar xvf -
gunzip -c subverison-1.6.9.tar.gz | tar xvf -
Cd subversion-1.6.9/apr
CC="/usr/vac/bin/cc" CFLAGS="-qmaxmem=-1 -O2 -qlanglvl=extended" ./configure 
--enable-shared --enable-static
make; make install
cd ../apr-util/xml/expat
CC="/usr/vac/bin/cc" CFLAGS="-qmaxmem=-1 -O2 -qlanglvl=extended" ./configure 
--enable-shared=yes
make; make install
cd ../..
CC="/usr/vac/bin/cc" CFLAGS="-qmaxmem=-1 -O2 -qlanglvl=extended" ./configure 
--with-apr=/usr/local/apr --with-expat=builtin
make; make install
cd ../neon
CC="/usr/vac/bin/cc" CFLAGS="-qmaxmem=-1 -O2 -qlanglvl=extended" 
CPPFLAGS="-I/usr/local/include" -LDFLAGS="-brtl" ./configure 
--with-expat=/usr/local/lib/libexpat.la --enable-shared=yes
make; make install
cd ..
CC="/usr/vac/bin/cc" CFLAGS="-qmaxmem=-1 -O2 -qlanglvl=extended" 
CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure 
--disable-shared --without-ssl --without-berkeley-db --with-apr=/usr/local/apr 
--with-apr-util=/usr/local/apr --without-apxs --with-neon=/usr/loca 
--without-serf
make; make install

Of course, before doing all this I tested it using the --prefix option to all 
configure to built it locally. When you do that you will have to adjust the 
--with-apr and --with-apr-util options to point to the locally installed apr 
and apr-util (I think I remember I had to add the bin directory at the end of 
the path, so something like /home/dev/local/apr/bin).

Give it a try. Maybe it won't work for you as is but it's a start.

Good luck
Giulio

How to merge from branch to trunk (was: No Subject)

[Ulrich Eckhardt]

Note up front: Choosing a meaningful subject makes sure your question is not 
getting ignored.

On Monday 08 March 2010, Ramachandran, Vishwanath(IE10) wrote:
> In a subversion working copy(XYZ), we are doing development in different
> branches. So the TRUNK contains the code base that is released to
> market.

So far, that is not unusual. However, maintenance releases normally occur from 
maintenance (bugfixing) branches. Further, I would tag something before 
releasing it. ;)

> There are different branches which are having different version of XYZ
> source.
>
> Currently we want to merge XYZ 1.2 version of branch to TRUNK.
>
>
> So instead of merge, we thought of doing COPY, because merge will take
> lot of efforts here because the trunk and the branch are different
> versions altogether.

Huh? About the copying, I'd say that that is a bad idea, because it breaks the 
history line of the trunk. I'd rather use merge.

Now, what I don't understand is why trunk and the branch are altogether 
different. Normally, you create a (feature) branch from trunk and then both 
for some time develop independently. Then, when the branch is stable, you 
merge the development back into trunk. Since both have a common ancestor, 
those merges should work. They should not be completely different.

Note: If they are too different to easily merge, you should perhaps update 
your branch with changes from the trunk more often. This helps identifying 
conflicts earlier and keeping them less severe.

> So for COPY, we are planning to do the following steps.
>
> 1) Move the TRUNK to a TAG using the SVN MOVE command.
>
> (2) Copy the BCM-WEB_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK.
>
>
> No need to do an explicit delete/commit on the trunk because svn move
> does a svn copy + svn delete and requires an immediate commit.
>
>
>
> Please review the steps and let us know its fine in terms of retaining
> SVN history etc

Actually, I'd say no, but I don't know what happened to trunk between forking 
off the branch and trying to merge it back. If I see that the trunk is 
replaced with a branch, that means to me that the development in trunk was 
abandoned and thrown away in favour of the development in the branch. If that 
is what you want to express, okay, otherwise I'd really just merge the 
changes into trunk.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: Could not un- and re- link ~/.subversion/config

[Alan Brogan]

On Mar 6, 2010, at 16:52, Ryan Schmidt wrote:

> As someone explained earlier in the thread, a Subversion client recreates the 
> ~/.subversion 
> directory when it runs, so something is causing a Subversion client to run. 

Oops! 

Apologies to Alexey for not appreciating the import of what he said on Thursday
and thanks to Ryan for the patience in re-highlighting it

Which was enough to point me towards the documentation I sought:
http://svnbook.red-bean.com/en/1.5/svn.advanced.confarea.html

-- 
Alan

P.S. FYI - "Something is causing the client to run"
Yes: my prompt changes the colour of the displayed $PWD depending on svn 
stat

SVN Copy

[Ramachandran, Vishwanath(IE10)]

Hi there

In a subversion working copy(XYZ), we are doing development in different
branches. So the TRUNK contains the code base that is released to
market.

 

There are different branches which are having different version of XYZ
source. 

Currently we want to merge XYZ 1.2 version of branch to TRUNK.

 

So instead of merge, we thought of doing COPY, because merge will take
lot of efforts here because the trunk and the branch are different
versions altogether.

 

So for COPY, we are planning to do the following steps.

 

1) Move the TRUNK to a TAG using the SVN MOVE command.

(2) Copy the XYZ_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK.

 

No need to do an explicit delete/commit on the trunk because svn move
does a svn copy + svn delete and requires an immediate commit.

 

Please review the steps and let us know, if its fine in terms of
retaining SVN history etc

 

 

Regards

Vishwanath

 

 

 

Re: SVN Copy

[Michael P. Reilly]

On Mon, Mar 8, 2010 at 9:04 AM, Ramachandran, Vishwanath(IE10) <
vishwanath.ramachand...@honeywell.com> wrote:

>  Hi there
>
> In a subversion working copy(XYZ), we are doing development in different
> branches. So the TRUNK contains the code base that is released to market.
>
>
>
> There are different branches which are having different version of XYZ
> source.
>
> Currently we want to merge XYZ 1.2 version of branch to TRUNK.
>
>
>
> So instead of merge, we thought of doing COPY, because merge will take lot
> of efforts here because the trunk and the branch are different versions
> altogether.
>
>
>
> So for COPY, we are planning to do the following steps.
>
>
>
> *1) Move the TRUNK to a TAG using the SVN MOVE command.*
>
> *(2) Copy the XYZ_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK.*
>
> * *
>
> *No need to do an explicit delete/commit on the trunk because svn move
> does a svn copy + svn delete and requires an immediate commit.*
>
>
>
> Please review the steps and let us know, if its fine in terms of retaining
> SVN history etc….
>
>
>
>
>
> Regards
>
> Vishwanath
>
You will not retain the history on the trunk.  The history breaks at the
point that you issue the move command.  There is a reason why there is a
'merge' and there are 'move/copy/delete'.  They are very different and each
is very necessary in its own way.

My first reaction to what you are trying to do is EW.  You're creating a
huge mess when you want to go back and look at the revision history of your
code.  You'll have to try to keep track of cross links between branches- why
does the history of the trunk suddenly stop at revision X and switch to
branch A?   Why does the history of branch A suddenly switch to the trunk?
Why can't I look at the history of the trunk older than six months ago
(assume branch A is five months old)?  How do I get that history back?

My suggestion to you is to clone the repository and try it out.  Then see
the ramifications - you will probably not be happy.  I will be much easier
on you later on to deal with the merge than to try to defeat the software
and create problems.

  -Arcege

-- 
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.

RE: SVN Copy

[Ramachandran, Vishwanath(IE10)]

Hi Michael

 

Thanks for the reply. You suggest to go for Merge instead of Copy?
Currently our SVN server is 1.4.6, we cannot implement Merge here. We
are in the process of upgrading the server. Any other alternative
solution for a temporary fix.

 

Regards

Vishwanath

 

 

From: Michael P. Reilly [mailto:arc...@gmail.com] 
Sent: Monday, March 08, 2010 7:50 PM
To: Ramachandran, Vishwanath(IE10)
Cc: users@subversion.apache.org
Subject: Re: SVN Copy

 

On Mon, Mar 8, 2010 at 9:04 AM, Ramachandran, Vishwanath(IE10)
 wrote:

Hi there

In a subversion working copy(XYZ), we are doing development in different
branches. So the TRUNK contains the code base that is released to
market.

 

There are different branches which are having different version of XYZ
source. 

Currently we want to merge XYZ 1.2 version of branch to TRUNK.

 

So instead of merge, we thought of doing COPY, because merge will take
lot of efforts here because the trunk and the branch are different
versions altogether.

 

So for COPY, we are planning to do the following steps.

 

1) Move the TRUNK to a TAG using the SVN MOVE command.

(2) Copy the XYZ_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK.

 

No need to do an explicit delete/commit on the trunk because svn move
does a svn copy + svn delete and requires an immediate commit.

 

Please review the steps and let us know, if its fine in terms of
retaining SVN history etc

 

 

Regards

Vishwanath

You will not retain the history on the trunk.  The history breaks at the
point that you issue the move command.  There is a reason why there is a
'merge' and there are 'move/copy/delete'.  They are very different and
each is very necessary in its own way.

My first reaction to what you are trying to do is EW.  You're
creating a huge mess when you want to go back and look at the revision
history of your code.  You'll have to try to keep track of cross links
between branches- why does the history of the trunk suddenly stop at
revision X and switch to branch A?   Why does the history of branch A
suddenly switch to the trunk?  Why can't I look at the history of the
trunk older than six months ago (assume branch A is five months old)?
How do I get that history back?

My suggestion to you is to clone the repository and try it out.  Then
see the ramifications - you will probably not be happy.  I will be much
easier on you later on to deal with the merge than to try to defeat the
software and create problems.
 
  -Arcege

-- 
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.

Re: SVN Copy

[Andy Levy]

On Mon, Mar 8, 2010 at 09:27, Ramachandran, Vishwanath(IE10)
 wrote:
> Hi Michael
>
>
>
> Thanks for the reply. You suggest to go for Merge instead of Copy? Currently
> our SVN server is 1.4.6, we cannot implement Merge here. We are in the
> process of upgrading the server. Any other alternative solution for a
> temporary fix.

Subversion still has merging prior to 1.5, it just doesn't have merge
*tracking*. Use svnmerge.py in the meantime to help keep track of
things.

>
>
> From: Michael P. Reilly [mailto:arc...@gmail.com]
> Sent: Monday, March 08, 2010 7:50 PM
> To: Ramachandran, Vishwanath(IE10)
> Cc: users@subversion.apache.org
> Subject: Re: SVN Copy
>
>
>
> On Mon, Mar 8, 2010 at 9:04 AM, Ramachandran, Vishwanath(IE10)
>  wrote:
>
> Hi there
>
> In a subversion working copy(XYZ), we are doing development in different
> branches. So the TRUNK contains the code base that is released to market.
>
>
>
> There are different branches which are having different version of XYZ
> source.
>
> Currently we want to merge XYZ 1.2 version of branch to TRUNK.
>
>
>
> So instead of merge, we thought of doing COPY, because merge will take lot
> of efforts here because the trunk and the branch are different versions
> altogether.
>
>
>
> So for COPY, we are planning to do the following steps.
>
>
>
> 1) Move the TRUNK to a TAG using the SVN MOVE command.
>
> (2) Copy the XYZ_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK.
>
>
>
> No need to do an explicit delete/commit on the trunk because svn move does a
> svn copy + svn delete and requires an immediate commit.
>
>
>
> Please review the steps and let us know, if its fine in terms of retaining
> SVN history etc….
>
>
>
>
>
> Regards
>
> Vishwanath
>
> You will not retain the history on the trunk.  The history breaks at the
> point that you issue the move command.  There is a reason why there is a
> 'merge' and there are 'move/copy/delete'.  They are very different and each
> is very necessary in its own way.
>
> My first reaction to what you are trying to do is EW.  You're creating a
> huge mess when you want to go back and look at the revision history of your
> code.  You'll have to try to keep track of cross links between branches- why
> does the history of the trunk suddenly stop at revision X and switch to
> branch A?   Why does the history of branch A suddenly switch to the trunk?
> Why can't I look at the history of the trunk older than six months ago
> (assume branch A is five months old)?  How do I get that history back?
>
> My suggestion to you is to clone the repository and try it out.  Then see
> the ramifications - you will probably not be happy.  I will be much easier
> on you later on to deal with the merge than to try to defeat the software
> and create problems.
>
>   -Arcege
>
> --
> There's so many different worlds,
> So many different suns.
> And we have just one world,
> But we live in different ones.

Re: SVN Copy

[Michael P. Reilly]

On Mon, Mar 8, 2010 at 9:27 AM, Ramachandran, Vishwanath(IE10) <
vishwanath.ramachand...@honeywell.com> wrote:

>  Hi Michael
>
>
>
> Thanks for the reply. You suggest to go for Merge instead of Copy?
> Currently our SVN server is 1.4.6, we cannot implement Merge here. We are in
> the process of upgrading the server. Any other alternative solution for a
> temporary fix.
>
>
>
> Regards
>
> Vishwanath
>
Why can you not perform a merge operation on a 1.4 server?  I've been
performing complex merge operations for five years going back to at least
1.3.x servers and probably before that with SVN 1.2.

You perform the merge, and when you commit, you include the branch and
revision ranges of what was being merged in the comment string:

For example:
svn checkout  http://./trunk code-to-merge
svn merge -r 59:103 http://branches/foobar code-to-merge
svn commit -m 'Merged from /repos/.../branches/foo...@59:103' code-to-merge

You could also put this information inside attributes which is what 1.5.x
does, but I found that it was easier for the developers to handle it inside
the commit string.

  -Arcege

-- 
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.

RE: SVN Copy

[Ramachandran, Vishwanath(IE10)]

Ok, thank you for the reply

 

Regards

Vishwanath

 

 

 

From: Michael P. Reilly [mailto:arc...@gmail.com] 
Sent: Monday, March 08, 2010 8:12 PM
To: Ramachandran, Vishwanath(IE10)
Cc: users@subversion.apache.org
Subject: Re: SVN Copy

 

 

On Mon, Mar 8, 2010 at 9:27 AM, Ramachandran, Vishwanath(IE10)
 wrote:

Hi Michael

 

Thanks for the reply. You suggest to go for Merge instead of Copy?
Currently our SVN server is 1.4.6, we cannot implement Merge here. We
are in the process of upgrading the server. Any other alternative
solution for a temporary fix.

 

Regards

Vishwanath

Why can you not perform a merge operation on a 1.4 server?  I've been
performing complex merge operations for five years going back to at
least 1.3.x servers and probably before that with SVN 1.2.

You perform the merge, and when you commit, you include the branch and
revision ranges of what was being merged in the comment string:

For example:
svn checkout  http://./trunk code-to-merge
svn merge -r 59:103 http://branches/foobar code-to-merge
svn commit -m 'Merged from /repos/.../branches/foo...@59:103'
code-to-merge

You could also put this information inside attributes which is what
1.5.x does, but I found that it was easier for the developers to handle
it inside the commit string.

  -Arcege


-- 
There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.

RE: The use of SVNROOT

[Eramo, Mark]

>There is no equivalent of CVSROOT in Subversion. But when it has been asked 
>for before, the response has been: what do you need it for? If you just want a 
>shortcut for checking out, define an environment variable and use that. This 
>is what I do in my ~/.bashrc:
>
>export M="http://svn.macosforge.org/repository/macports";
>
>Then I can for example:
>
>svn checkout $M/trunk/dports
>
>or
>
>svn log $M --limit 5
>
>I use the variable "M" because it's easy to remember that it stands for 
>MacPorts and I'm not using it for anything else, but you can name it anything 
>you want, or define multiple env vars for multiple repositories or multiple 
>paths within a repository (for example, >a separate variable for the trunk, or 
>for a deep path within the repo that you often want to refer to).
>
>Remember, the working copy stores the repository URL it was checked out from, 
>so the only time you need the repository URL is when you're checking out or 
>when you're asking for a log or similar function and aren't already sitting in 
>the working copy's directory.

Thanks for the reply Ryan. I was thinking about doing something like this but I 
wanted to confirm the need of SVNROOT first.

Regards,

Mark

Re: SVN Copy

[Stein Somers]

I'm not sure if this is what you mean with those commands, but if in the 
end what you want a single path like /trunk to show you the timeline of 
releases, e.g.


trunk 1789 copy of /tags/XYZ_1.3.0_BUILD32_RELEASE_RC1
trunk 1234 copy of /tags/XYZ_1.2.0_BUILD24_RELEASE_RC1
trunk  copy of /tags/XYZ_1.1.0_BUILD11_RELEASE_RC1

then I think that, apart from the name "trunk", that sounds more than 
reasonable. It is much more quick, clear and robust than merging in 
changes and hoping the result is the same as a copy.


I think you'd have a problem getting the listing above with tools trying 
to "follow" the copy of a root folder. But I hope an additional 
subdirectory would fix that. Just have a single directory called "link" 
in trunk and the log of trunk should show:


trunk/link 1789 copy of /tags/XYZ_1.3.0_BUILD32_RELEASE_RC1
trunk/link 1234 copy of /tags/XYZ_1.2.0_BUILD24_RELEASE_RC1
trunk/link  copy of /tags/XYZ_1.1.0_BUILD11_RELEASE_RC1

However, why you would use the name "trunk" for this? A trunk is usually 
where branches grow out from, not where you stick them into!


--
Stein

Re: SVN Copy

[Les Mikesell]

On 3/8/2010 8:04 AM, Ramachandran, Vishwanath(IE10) wrote:

Hi there

In a subversion working copy(XYZ), we are doing development in different
branches. So the TRUNK contains the code base that is released to market.

There are different branches which are having different version of XYZ
source.

Currently we want to merge XYZ 1.2 version of branch to TRUNK.

So instead of merge, we thought of doing COPY, because merge will take
lot of efforts here because the trunk and the branch are different
versions altogether.

So for COPY, we are planning to do the following steps.

/1) Move the TRUNK to a TAG using the SVN MOVE command./

/(2) Copy the XYZ_1.2.0_BUILD24_RELEASE_RC1 TAG to the TRUNK./

/ /

/No need to do an explicit delete/commit on the trunk because svn move
does a svn copy + svn delete and requires an immediate commit./

Please review the steps and let us know, if its fine in terms of
retaining SVN history etc….


Is there some particular reason you need to release from the trunk?  And 
is it worth breaking the continuity of history so you'd have to use peg 
revision numbers to go backwards there?


If you use a model where most development happens on the trunk and you 
branch as you near a release and need the trunk to advance with features 
that won't be included in this release, then complete the release from 
the branch you can avoid all of the mess and as a side effect make it 
much easier to support overlapping releases if that is ever necessary.


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

Re: SVN Copy

[Stein Somers]

but if in the
end what you want a single path like /trunk to show you the timeline of
releases,


And by the way, this is called a "moving tag" in SVN circles (or maybe 
everywhere).


--
Stein

Re: How to recover from "Found malformed header in revision file"?

[Steven Roussey]

I can do a full checkout at the moment. Too bad I can't go from that
and create a new repo. Anyhow, the svnsync idea is a good one, and
I'll have to give that a try. Thanks!

Steven Roussey
Network54 Corp.



2010/3/3 Mariusz Droździel :
> On 4 March 2010 03:24, Steven Roussey  wrote:
>
>> I also tried svnadmin recover which did not work, and fsfsverify.py. I have a
>> few working copies around that are ok (I think) -- is there a way to use 
>> that to
>> fix the repository?
>
> Check out "Corrupted FSFS commit" and "Broken Revision in FSFS Repo"
> threads from few days ago. I think me and Martin had very similiar
> problem and solved it out with svnsync + access control over webdav.
>
> --
> Mariusz Drozdziel
>

Re: Programming a Watcher File

[David Weintraub]

I'm almost finished my second notification scheme. Each user their own
watch file. In my access-control trigger, I can easily set it up, so
that users can only change their own watch files:

[FILE Lock Watch directory as read-only]
file = ^/watchers/.*
access = read-only
users = @ALL

[FILE Now allow users to edit their own watch file]
file = ^/watchers/.cfg
access = read-write
users = 

Watch files will be composed of three lines. The first is the email line:

email = qazw...@gmail.com

Users can have as many email lines as their heart desires, and I'll
email each and every one of them. If the user doesn't have an email
line in their file, I'll email to @ which is
pretty much what you expect as the default.

There are two other lines in the file:

file = /foo/trunk/mail/src/java/**/*.java

and

regex = ^foo/.*\.java$

The "file" line is for Ant glob type expressions where "*" is a series
of any characters except "/" and "**" is any series of characters. It
is automatically anchored at the root of repository it is expected to
match the entire file name. The "regex" is an extended regular
expression that matches the file name. It is not anchored unless you
use the "^" and "$" characters.

Of course, I don't notify the user of self changes.

I am still testing, but I'm willing to give this to anyone who wants to try it.

The other watch file trigger is for a manager to specify who gets
notified of what type of change and by whom. It's a lot more specific
to our circumstance where we want QA people in India to be notified of
changes developers in NY do, and QA people in New York to be notified
of developer changes in India.


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

Re: Programming a Watcher File

[Daniel Becroft]

On Wed, Mar 3, 2010 at 2:26 AM, David Weintraub  wrote:

> One of the tech leads wants to be able to program a watch file, so
> that when a certain set of developers change a particular file,
> certain other developers get notified. Thus, we need to be able to
> program what files, what developers do the commit, and what developers
> receive the notification. I'd like to do this, so this developer can
> maintain this file himself instead of me having to maintain it which
> means it can't be a text file on the Subversion server.
>
> I'm working with something like this now. I have a configuration file
> where you setup the various parameters (specifying files via globbing
> or regex), who does the commit, and who receives the email. The
> configuration file sits in the source repository, so this tech lead
> has access to it.
>
> I was wondering if anyone already has a post-commit hook script like
> this already setup. I know there's one included in Subversion, but
> this one uses a text file that's accessible to the hook script and its
> setup isn't that flexible.
>
> If not, I'll finish up the one I'm working on.
>
>
Probably a bit too late now, but have you considered using a tool such as
CommitMonitor, or SVNNotifier?

Cheers,
Daniel B.

Re: Programming a Watcher File

[David Weintraub]

CommitNotifier uses Tortoise and SVN Notifier uses MS .NET platform.
Both are Windows specific, and we have a really mixed office. We have
people on Linux, Windows, and Mac.

On Mon, Mar 8, 2010 at 5:49 PM, Daniel Becroft  wrote:
> On Wed, Mar 3, 2010 at 2:26 AM, David Weintraub  wrote:
>>
>> One of the tech leads wants to be able to program a watch file, so
>> that when a certain set of developers change a particular file,
>> certain other developers get notified. Thus, we need to be able to
>> program what files, what developers do the commit, and what developers
>> receive the notification. I'd like to do this, so this developer can
>> maintain this file himself instead of me having to maintain it which
>> means it can't be a text file on the Subversion server.
>>
>> I'm working with something like this now. I have a configuration file
>> where you setup the various parameters (specifying files via globbing
>> or regex), who does the commit, and who receives the email. The
>> configuration file sits in the source repository, so this tech lead
>> has access to it.
>>
>> I was wondering if anyone already has a post-commit hook script like
>> this already setup. I know there's one included in Subversion, but
>> this one uses a text file that's accessible to the hook script and its
>> setup isn't that flexible.
>>
>> If not, I'll finish up the one I'm working on.
>>
>
> Probably a bit too late now, but have you considered using a tool such as
> CommitMonitor, or SVNNotifier?
>
> Cheers,
> Daniel B.
>
>
>



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

Re: Programming a Watcher File

[Les Mikesell]

On 3/8/2010 4:56 PM, David Weintraub wrote:

CommitNotifier uses Tortoise and SVN Notifier uses MS .NET platform.
Both are Windows specific, and we have a really mixed office. We have
people on Linux, Windows, and Mac.


Hudson should run on about anything. It does have to poll for changes 
but it can do about anything in the job that it kicks off, even on 
remote slave machines.


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

Re: Programming a Watcher File

[David Weintraub]

The idea is to allow users to specify exactly which they want to
watch. It might be a few configuration files, images, etc.

Hudson will notify if any files in the entire project are changed, and
when you do a dozen builds each day, the developers start to ignore
these build notices.

This is something that most other version control systems allow and is
usually built in. Third party clients like SVN Notifier and Commit
Notifier is that they must be user installed and running on the user's
machine. If you aren't on that machine, you don't get notified.

Something like Fisheye is good because that allows users to set
notifications and is not dependent upon the user's own system.
However, we don't have Fisheye.

Subversion comes with a post-commit notification script written in
Perl, but this script requires a configuration file that sits on the
server. That means developers have to ask the administrator to set and
change notifications.  By putting the notification configurations
inside the repository, I allow users to set their own notifications.
Since it is the server that's running it, the notifications aren't
machine dependent.

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

svn 1.6x and apache compression - mod_deflate

[Leszek Szarlej]

Hi

In svn book ver. 1.0 there is written:
"Deflate compression places a small burden on the client and server to
compress and decompress network transmissions as a way to minimize the size
of the actual transmission. In cases where network bandwidth is in short
supply, this kind of compression can greatly increase the speed at which
communications between server and client can be sent. In extreme cases, this
minimized network transmission could be the difference between an operation
timing out or completing successfully."
In the same book in version 1.5 there is no word about why/why not. Is it
mean that mod_deflate is not recomended for current versions of svn? I did
tests on svn 1.6.9 and compression rate is about 30-40 percent and checkout
times are ~30%  less

Thanks
Leszek