Re: how to replicate svn-lock on mirrored repository
Hi, since nobody took it up, I’ll take a stab at it: Am 24.11.2014 10:42, schrieb Senthilvelu: any help? On Friday, 21 November 2014 12:16:32 UTC+5:30, Senthilvelu wrote: I have a mirrored repository which is generated from a source repository. it is getting update regularly. when a user checks out with lock on source repo, i want this to be update on the mirror repo, which is not happening using svnsync. is there anyway i can update the lock as well on the mirror repo thanks senthil Usually, you shouldn’t need to exert any special effort to forward locks to the mirror. The property svn:needs-lock is a normal property, so it gets synced out to the mirror with the normal procedure. When a client tries to get a lock on a file, it always asks the master, when someone else has the lock, the client will get told even without the mirror having to do anything. So, there is no reason for the mirror to know. Does this help? Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: Breaking up a monolothic repository
Am 10.09.2013 19:45, schrieb Thomas Harold: When we moved from a monolithic repository to per-client repositories a few years ago, we went ahead and: - Rebased the paths up one or two levels (old system was something like monolithicrepo/[a-z]/[client directories]/[job directory]) so that the urls were now clientrepo/[job directory]. That was a tricky thing to do and we had to 'sed' the output of the dump filter before importing it back. It broke a few things, such as svn:externals which were not relative-pathed, but was worth it in the long run so that our URLs got shorter. - Made sure that the new repos all had unique UUIDs. - Renumbered all of the resulting revisions as we loaded things back in. But we didn't have to deal with any bug tracking systems that referred to a specific revision. And having lower revision numbers was preferred, along with dropping revisions that referred to other projects. I'm now facing the same problem. My users want the rebasing, but during the dump/load instead of after the fact (apparently, it causes issues with their environment when they need to go back to an earlier revision to reproduce something). They also want to keep the empty revisions (for references from the issue tracker). I haven't tried it with svnadmin dump followed by svndumpfilter (I don't think it has that capability). I've tried svnrdump (from svn 1.7), it resulted in either a new repository with the full path included (rdump/load all revs) or an interesting failure mode with a missing node during a copy operation when rdump -r revision_after_path:HEAD was used I've also tried using svnsync, but that also results in the full path included, no rebasing. How did you do it? Also, am I missing something that has been included in a current svn version? Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
Re: Strange behavior
Am 09.08.2013 21:58, schrieb Edwin Castro: On 8/9/13 10:27 AM, John Maher wrote: And svn status returns this: C Build.bat local add, incoming add upon merge You svn add Build.bat in trunk. Later you svn add Build.bat in your branch. Subversion sees those as separate objects with individual history. I've seen this here, too. It seems to be related to a user creating a branch with the OS tools without telling SVN about it, then adding it to SVN, then porting over changes by hand, then trying to merge in more changes... To create a branch, I've learned to always do an svn copy between URLs, e.g. svn cp file:///repository/trunk file:///repository/branches/mybranch. Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
