Re: Do I need to use same APR between apache and subversion?
On Mon, Jun 6, 2011 at 4:04 PM, Sam Theman wrote: > Hello, > > I am currently running subverison 1.6.11 with apache 2.2.15 > > I need to go to subversion 1.6.17. So I was just going to build > subversion1.6.17 svn modules and put them into the apache2 modules > directory. > > I tried to build subversion 1.6.17 with the apr libs from apache 2.2.15 but > got an error trying to build subversion. I am thinking I need to install > fresh standalone apr's and then build subversion using the new standalone > aprs. Will this work, or do I need to use the same apr's between apache and > subversion? > > thanks, > Sam Unless you are building it *statically*, which makes it bulkier and prevents you from getting updates when you update your Apache libraries, you'll need to use the same versions. What OS and Apache version do you already have in place? Also note, it could be worse, I just got to check trying to compile Subversion on a legacy SuSE system with Apache 1.3.x, and the set of toolchains was long enough that I finally threw in the towel, and am using it as leverage to try and get the system upgraded.
Re: Two-Site Subversion Repository Setup Ideas
On Mon, Jun 6, 2011 at 6:16 AM, Stefan Sperling wrote: > On Mon, Jun 06, 2011 at 11:55:42AM +0200, Andreas Tscharner wrote: >> People here will hate me for this, but I think you should switch to a >> DVCS (Distributed Version Control System), like Mercurial or git. > > If people hate you for making this suggestion then that's their fault. > Not every tool is made for every imaginable job. > > The use case described is a good fit for distributed tools because > it is part of the problem domain they have been designed for. Actually, I don't think we know that. The security based refusal to allow electronic communications between the systems will hamper *any* multi-homed development effort. We need to find out the extent of that restriction to give good advice.
Re: Two-Site Subversion Repository Setup Ideas
On 6/7/11 6:52 AM, Nico Kadel-Garcia wrote: On Mon, Jun 6, 2011 at 6:16 AM, Stefan Sperling wrote: On Mon, Jun 06, 2011 at 11:55:42AM +0200, Andreas Tscharner wrote: People here will hate me for this, but I think you should switch to a DVCS (Distributed Version Control System), like Mercurial or git. If people hate you for making this suggestion then that's their fault. Not every tool is made for every imaginable job. The use case described is a good fit for distributed tools because it is part of the problem domain they have been designed for. Actually, I don't think we know that. The security based refusal to allow electronic communications between the systems will hamper *any* multi-homed development effort. We need to find out the extent of that restriction to give good advice. Yes, I have a hard time visualizing how any tool can help with concurrent changes if one side doesn't stop while the merges happen both ways and the results get back. Some may be better at permitting the teams to keep working while the code diverges, but that's not necessarily a good thing. Particularly if other forms of communication are equally hampered. -- Les Mikesell lesmikes...@gmail.com
Re: Two-Site Subversion Repository Setup Ideas
Am Dienstag, den 07.06.2011, 08:13 -0500 schrieb Les Mikesell: > Yes, I have a hard time visualizing how any tool can help with > concurrent changes if one side doesn't stop while the merges happen > both ways and the results get back. Just look at Clearcase (again, sorry :) ). First, it has excellent merge (tracking) capabilities. People can merge between branches in BOTH directions as often as they like/need. And secondly, it prohibits working on branches which don't belong to the local replica. That means that users on other sites are forced to work on branches, which are different from the branches being worked on at the local site. If you are used to working with branches, it doesn't matter anymore from which site it comes. > Some may be better at permitting the teams to keep working while the > code diverges, but that's not necessarily a good thing. Well, it is a good thing. That's the purpose of version control systems, letting people keep working while the code diverges. Having different replicas of the same repository is just "syntactic sugar". Bye... Dirk Firma: Capgemini Deutschland GmbH Geschaeftsfuehrer: Dr. Michael Schulte (Vorsitzender), Sven Breipohl, Burkhard Kehrbusch, Peter Laggner, Josef Ranner Amtsgericht Berlin-Charlottenburg, HRB 98814 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. signature.asc Description: signature.asc
How to undo a switch?
Hello, I selected a file and chose ‘switch to’ a tag recently used to tag a release of my complete project. I mistakenly assumed that in doing so I would just switch the particular file to the version in the tagged release. However instead the result was that my file was converted into a folder of the same name which contained all the files/directories of the aforementioned tagged project. I just cannot find a way to reverse this, retrieve the correct version of my file, and keep SVN happy at the same time. Appreciate any help. Bill Herring Yellowbrick Tracking.
Re: How to undo a switch?
On Tuesday 07 June 2011, Bill Herring wrote: > I have just selected a file and chose ‘switch to’ a tag recently used to > tag a release of my complete project. I mistakenly assumed that in doing > so I would just switch the particular file to the version in the tagged > release. The reason that this doesn't work is that Subversion is a versioned storage for files. What many people consider tags or branches is completely irrelevant to Subversion itself, so it can't determine the "correct" file within your "project" when you switch a file to a certain "tag". BTW: In case you wonder if that is a bug or feature, I have used this feature to switch a file to a directory. > I just cannot find a way to reverse this, retrieve the correct version of > my file, and keep SVN happy at the same time. Just switch the directory back to the former URL, or directly to the actual file's URL that you wanted to switch it to in the first place. Cheers! Uli ** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** 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. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **
RE: How to undo a switch?
> -Original Message- > From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > Sent: dinsdag 7 juni 2011 17:06 > To: users@subversion.apache.org > Subject: Re: How to undo a switch? > > On Tuesday 07 June 2011, Bill Herring wrote: > > I have just selected a file and chose ‘switch to’ a tag recently used to > > tag a release of my complete project. I mistakenly assumed that in doing > > so I would just switch the particular file to the version in the tagged > > release. > > The reason that this doesn't work is that Subversion is a versioned storage > for files. What many people consider tags or branches is completely > irrelevant > to Subversion itself, so it can't determine the "correct" file within your > "project" when you switch a file to a certain "tag". > > BTW: In case you wonder if that is a bug or feature, I have used this feature > to switch a file to a directory. The current Subversion 1.7 development snapshot warns you when you do this and requires that you pass --ignore-ancestry if you really want to switch to something unrelated. Bert
Tree conflict: Add/Add on directory
Hi,
I'm having trouble resolving a tree conflict.
I'm working on a feature branch, and I regularly merge from trunk to the
branch. In my latest merge, I got a tree conflict because a directory
("playback") has been added both to trunk and to my branch, with
different contents. I want to get rid of my version and use the one
from trunk.
This should be trivial, but it isn't:
$ svn resolve --accept theirs-full playback
svn: warning: Tree conflicts can only be resolved to 'working' state;
'playback' not resolved
So I thought I'd delete the directory and use "svn cp" to copy the
branch version into my working copy. The delete worked:
$ svn st --depth=empty playback
D C playback
> local add, incoming add upon merge
And I can easily get the URL I need to copy from:
$ svn info playback
URL: http://svnserver/repos/branches/feature/wherever/playback
...
Tree conflict: local add, incoming add upon merge
Source left: (dir)
http://svnserver/repos/trunk/wherever/playback@2373
Source right: (dir)
http://svnserver/repos/trunk/wherever/playback@3515
But the copy doesn't work:
$ svn cp http://svnserver/repos/trunk/wherever/playback@3515 .
svn: Path 'playback' already exists
(I also tried "svn cp
http://svnserver/repos/trunk/wherever/playback@3515 playback", but that
put it in the wrong place (playback/playback/ rather than just
playback/) and seemed to get my working copy in a bugged state,
requiring non-SVN "rm" and "svn cleanup" to get it working again).
I guess I could split the commit into two - if I did a first commit for
the rest of the merge and to delete the "playback" directory, I'd
probably be able to use "svn cp" and do a second commit to re-add it
with the right contents. This seems like a very ugly hack.
Any ideas how to resolve this properly?
Kind regards,
Jon
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: Tree conflict: Add/Add on directory
On Tue, Jun 07, 2011 at 07:08:44PM +0100, Jon Foster wrote:
> Hi,
>
> I'm having trouble resolving a tree conflict.
>
> I'm working on a feature branch, and I regularly merge from trunk to the
> branch. In my latest merge, I got a tree conflict because a directory
> ("playback") has been added both to trunk and to my branch, with
> different contents. I want to get rid of my version and use the one
> from trunk.
>
> This should be trivial, but it isn't:
>
> $ svn resolve --accept theirs-full playback
> svn: warning: Tree conflicts can only be resolved to 'working' state;
> 'playback' not resolved
Hi Jon, long time no see.
I hope your svnsync jobs are still running safely :)
As the error message explains, interactive conflict resolution isn't
implemented yet for tree conflicts. Sorry.
I hope this will be worked on for Subversion 1.8.
> So I thought I'd delete the directory and use "svn cp" to copy the
> branch version into my working copy. The delete worked:
>
> $ svn st --depth=empty playback
> D C playback
> > local add, incoming add upon merge
>
> And I can easily get the URL I need to copy from:
>
> $ svn info playback
> URL: http://svnserver/repos/branches/feature/wherever/playback
> ...
> Tree conflict: local add, incoming add upon merge
> Source left: (dir)
> http://svnserver/repos/trunk/wherever/playback@2373
> Source right: (dir)
> http://svnserver/repos/trunk/wherever/playback@3515
>
> But the copy doesn't work:
> $ svn cp http://svnserver/repos/trunk/wherever/playback@3515 .
> svn: Path 'playback' already exists
> (I also tried "svn cp
> http://svnserver/repos/trunk/wherever/playback@3515 playback", but that
> put it in the wrong place (playback/playback/ rather than just
> playback/) and seemed to get my working copy in a bugged state,
> requiring non-SVN "rm" and "svn cleanup" to get it working again).
>
> I guess I could split the commit into two - if I did a first commit for
> the rest of the merge and to delete the "playback" directory, I'd
> probably be able to use "svn cp" and do a second commit to re-add it
> with the right contents. This seems like a very ugly hack.
>
> Any ideas how to resolve this properly?
The problem is that the 1.6 working copy does not support
directory replacements properly. Think about what should happen
to the .svn directory in the locally deleted directory. It needs
to remain in place so you can revert your deletion if you decide
to do so. But it also interferes with adding a new directory before
you commit the deletion, because the new directory would need
a different .svn directory at the same place!
So you really need two commits.
However, your approach should perfectly work fine with a 1.7 client
because meta-data has been centralised in a single .svn directory
in the root directory of the working copy. So if you got time please
try the 1.7.0-alpha1 release which should hopefully be released during
the next couple of days and report back. Thanks!
BTW, replacing directories does work more or less by accident in some
situations in 1.6, e.g. if a merge brings in both the delete and add
parts of a directory replacement -- but that is a small miracle and
your situation is one where it does not work at all.
