On Wed, Jun 30, 2010 at 4:41 PM, Roberto de Castro wrote:
> Hi Csaba Raduly!
> This is Event Viewer log message:
> Log Name: System
> Source: Service Control Manager
> Date: 30/06/2010 11:32:57
> Event ID: 7000
> Task Category: None
> Level: Error
> Keywords:
Hi Gurus,
Kindly help me with my problem.
Subversion is running fine for sometime and then system load suddenly
goes high and no one can login to the server.
172.23.14.1 - - [01/Jul/2010:10:18:36 +0800] "PROPFIND
/xyz/branches/prod HTTP/1.1" 401 1263
172.23.14.1 - - [01/Jul/2010:10:18:36 +0800]
Hello,
I am a long term subversion user and use it in my everyday work.
Sometimes happens to me that I checkout a local copy of some directory in
the repository from a low speed modem connection, if the directory
contains a huge file the download time can be extremely high. Because I am
not partic
Yeah, thanks!
Your answer is along the lines of what I've been thinking. Using the repo
browser or hook-script. Best would probably be to introduce a hook script which
forbids people to branch from an older version than was previously branched. An
example of such a script would be GREATLY appre
Hi!
Thanks for reply.
Well it was possible. And I'm pretty sure server was 1.6 at the time. All users
are using TortoiseSVN.
The revision 1174 was copied from 1112 but 1151 had replaced 1146(!!) so 1174
lost everything after 1112! Since user2 hadn't updated to revision 1173 in the
"from"-branc
Thank you Bob!
-Ursprüngliche Nachricht-
Von: Bob Archer [mailto:bob.arc...@amsi.com]
Gesendet: Mittwoch, 30. Juni 2010 17:53
An: Graf, Andreas; Giulio Troccoli; users@subversion.apache.org
Cc: Bruedern, Ivonne
Betreff: RE: Reintegrate merge to another branch
>>> From: Graf, Andreas [mai
> -Original Message-
> From: Jan Lund [mailto:janne_l...@yahoo.com]
> Sent: Wednesday, June 30, 2010 11:28 AM
> To: users@subversion.apache.org
> Subject: out of date branches
>
> Hi all,
>
> I would like to know if there are any recommendations as to enforce
> a team to always branch fro
>>> From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com]
>>> We are using Tortoise reintegrate successfully to merge changes
>>> back to the branch that have been used for branch-off.
>>>
>>> But if we are using reintegrate to apply the same differences to
>>> another branch, we are gett
Subversion doesn’t allow you to commit changes to out of date files and with
Subversion 1.6 you would get a tree conflict on updating the replaced file.
This tree conflict would explain that there were changes to the file that you
replaced.
Bert
From: Jan Lund [mailto:jan
Hi all,
I would like to know if there are any recommendations as to enforce a team to
always branch from the latest revision of a branch. There's a big risk that a
developer might have forgotten to update a branch, then does a replace (in
TortoiseSVN) which overwrites a more recent version of a
Hi Giulio,
Thank you for your comments.
From my point of view, the bennefit of reintegrate is that users do not
have to take care about the used revisions, so we would like to use that
functionality for submitting changes to other branches too. For instance
when we have to provide patches
>
> Hi Justin,
>
> On Fri, Jun 25, 2010 at 09:09:39AM -0500, Justin Johnson wrote:
>
> > I am attempting to import a file and set svn:eol-style in one command
> using
> > the --auto-props and --config-option options to svn import. When I do
> the
> > import I explicitly specify the file name in th
I don't think is possible to use --reintegrate. You can always to a "old style"
merge with a revision range.
But there is something I don't understand. I presume you have created both
branches from trunk, so after you have reintegrated the first branch, isn't it
ebough to do a merge from trunk
Hi SVN folks!
We are using Tortoise reintegrate successfully to merge changes back to
the branch that have been used for branch-off.
But if we are using reintegrate to apply the same differences to another
branch, we are getting bad merge results.
Is there a bug-fix for that problem availa
Hello,
I agree that dump/restore is the best option but in some cases,
a repository may be so large that dump/restore is unpratical.
The "svnadmin upgrade" command is a minimal operation to do but your repository
structure will not be sharded (if it comes from 1.4 for instance).
My preference i
15 matches
Mail list logo
