Re: Sync-ing two SVN repositories
On Jul 20, 2015, at 10:08 AM, Mani Raju wrote: > My company & vendor planning to maintain 2 independent SVN repositories(URLs > & server names are different) & need to merge between 2 repositories. > > Is SVN 1.8 support merging between 2 repos at trunk or branch level? > Is any tool provides auto sync or auto merging without manual intervention > > Tried with TortoiseSVN by creating 2 repositories, merged & getting the > below error.Refer attached. > > ERROR --> svn: 'x' isn't in the same repository as 'y' " > > I got the below link to sync between branches from different > repositories.Provided solution in this link is to maintain > the same UUID for both repo.So I am guessing we can sync at branch level. > > http://stackoverflow.com/questions/3907162/svn-error-x-isnt-in-the-same-repository-as-y-during-merge Don't set two repositories to the same UUID unless their contents are intended to be completely identical (and such identicalness will be maintained by use of the svnsync program). Even if you have two repositories that are identical to each other, one of them will need to be designated the "master", and that will be the one that all commits are made to. Subversion is a one-central-repository system.
Aw: Re: Sync-ing two SVN repositories
Hello, > On Jul 20, 2015, at 10:08 AM, Mani Raju wrote: > > > My company & vendor planning to maintain 2 independent SVN > > repositories(URLs & server names are different) & need to merge between 2 > > repositories. > > > > Is SVN 1.8 support merging between 2 repos at trunk or branch level? > > Is any tool provides auto sync or auto merging without manual intervention > > > > Tried with TortoiseSVN by creating 2 repositories, merged & getting the > > below error.Refer attached. > > > > ERROR --> svn: 'x' isn't in the same repository as 'y' " > > > > I got the below link to sync between branches from different > > repositories.Provided solution in this link is to maintain > > the same UUID for both repo.So I am guessing we can sync at branch level. > > > > http://stackoverflow.com/questions/3907162/svn-error-x-isnt-in-the-same-repository-as-y-during-merge > > Don't set two repositories to the same UUID unless their contents are > intended to be completely identical (and such identicalness will be > maintained by use of the svnsync program). > > Even if you have two repositories that are identical to each other, one of > them will need to be designated the "master", and that will be the one that > all commits are made to. > > Subversion is a one-central-repository system. Unless of course one of the lesser known features is used: Cross-repository copies and merges actually work (to not use the term "supported"). Copies/moves will become additions, inter-revision history is compessed and there is no merge tracking. See the three-agrument (copy or) merge syntax "svn merge A@N A@M .", where A and "." refer to different repositories. Not that it's recommended in the user's case, but it should be mentioned. Best approach in the svn space for Mani would be vendor branches based on the information shared. Andreas
RE: Feature request: Save the old file when svn revert
That's actually not a bad idea ... I've been burnt by this one a couple of times myself. Probably worth raising it with the d...@subversion.apache.org list to see if it's something that they've considered previously. David. -- David Grierson - SDLC Tools Specialist Sky Broadcasting - Customer Business Systems - SDLC Tools Email: david.grier...@sky.uk Watermark Building, Alba Campus, Livingston, EH54 7HH > -Original Message- > From: 牛暁冬 [mailto:neoedm...@gmail.com] > Sent: 20 July 2015 03:04 > To: users@subversion.apache.org > Subject: Feature request: Save the old file when svn revert > > "svn revert" will delete the local changes and nowhere to find, which > is dangerous. > I suggest the default behaiver should be save the local changed > file(if any) to "filename.local" and do the revert. > > Thanks > Neoe Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
Re: Feature request: Save the old file when svn revert
Hello, David Grierson wrote: > > "svn revert" will delete the local changes and nowhere to find, which > > is dangerous. > > I suggest the default behaiver should be save the local changed > > file(if any) to "filename.local" and do the revert. > > > That's actually not a bad idea ... I've been burnt by this one a couple of > times myself. > > Probably worth raising it with the d...@subversion.apache.org list to see if > it's something that they've considered previously. Actually a feature in at least one GUI client: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-dialogs Otherwise it's rather platform specific to implement, and may be better suited for integrated clients. Andreas
RE: Feature request: Save the old file when svn revert
I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific. To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific? Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE. -- David Grierson - SDLC Tools Specialist Sky Broadcasting - Customer Business Systems - SDLC Tools Email: david.grier...@sky.uk Watermark Building, Alba Campus, Livingston, EH54 7HH > -Original Message- > From: Andreas Stieger [mailto:andreas.stie...@gmx.de] > Sent: 21 July 2015 09:38 > To: Grierson, David > Cc: 牛暁冬; users@subversion.apache.org > Subject: Re: Feature request: Save the old file when svn revert > > Hello, > > David Grierson wrote: > > > "svn revert" will delete the local changes and nowhere to find, which > > > is dangerous. > > > I suggest the default behaiver should be save the local changed > > > file(if any) to "filename.local" and do the revert. > > > > > That's actually not a bad idea ... I've been burnt by this one a couple > of times myself. > > > > Probably worth raising it with the d...@subversion.apache.org list to see > if it's something that they've considered previously. > > Actually a feature in at least one GUI client: > http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug- > settings.html#tsvn-dug-settings-dialogs > Otherwise it's rather platform specific to implement, and may be better > suited for integrated clients. > > Andreas Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
Re: Feature request: Save the old file when svn revert
Grierson, David wrote: I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific. To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific? Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE. I would very much prefer if this could be an option that is not enabled by default. I mean, this would clutter the filesystem with many files that one would have to delete manually, especially when considering that some of us are using less than optimal filesystems when it comes down to lots of small files.
RE: Feature request: Save the old file when svn revert
Apologies for the previous top-posting ... I hate Outlook sometimes. > -Original Message- > From: OBones [mailto:obo...@free.fr] > Sent: 21 July 2015 10:06 > To: Grierson, David; Andreas Stieger > Cc: 牛暁冬; users@subversion.apache.org > Subject: Re: Feature request: Save the old file when svn revert > > Grierson, David wrote: > > I completely understand that the action of sending to the Recycle Bin > (in TortoiseSVN) is very system specific. > > > > To simply rename the item being reverted as $item.$backupSuffix before > then restoring the pristine item is presumably not that system specific? > > > > Having this functionality in the base tool would then provide a benefit > to all users and not just those using a specific IDE. > I would very much prefer if this could be an option that is not enabled > by default. I mean, this would clutter the filesystem with many files > that one would have to delete manually, especially when considering that > some of us are using less than optimal filesystems when it comes down to > lots of small files. Presumably only if you're doing a lot of reverts and surely that's going to be negligible compared with the existing hit you're receiving from the working copy files. Dg. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
AW: Feature request: Save the old file when svn revert
Hi, Von: Grierson, David [mailto:david.grier...@sky.uk] > From: 牛暁冬 [mailto:neoedm...@gmail.com] > > "svn revert" will delete the local changes and nowhere to find, > > which is dangerous. > > I suggest the default behaiver should be save the local changed > > file(if any) to "filename.local" and do the revert. > > That's actually not a bad idea ... I've been burnt by this one a > couple of times myself. > > Probably worth raising it with the d...@subversion.apache.org list to > see if it's something that they've considered previously. I'm not really sure what to think about this one... In the end, the whole purpose of "svn revert" is to drop the local changes and *revert* everything back to the state the repository has. All other commands need a --force or other explicit user decision to override user changed data, but the whole purpose of the "svn revert" command is to undo local changes - putting a --force option or something similar seems like a bit of contradiction. On the other hand, I'm not an SVN core developer, so it's just my personal opinion. How do the other RCSes handle this situation? Maybe we can learn some ideas for a nice(r) UI there... Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Feature request: Save the old file when svn revert
> -Original Message- > From: Markus Schaber [mailto:m.scha...@codesys.com] > Sent: 21 July 2015 14:01 > To: Grierson, David; d...@subversion.apache.org > Cc: 牛暁冬; users@subversion.apache.org > Subject: AW: Feature request: Save the old file when svn revert > ... > I'm not really sure what to think about this one... > > In the end, the whole purpose of "svn revert" is to drop the local > changes and *revert* everything back to the state the repository has. > > All other commands need a --force or other explicit user decision to > override user changed data, but the whole purpose of the "svn revert" > command is to undo local changes - putting a --force option or > something similar seems like a bit of contradiction. > > On the other hand, I'm not an SVN core developer, so it's just my > personal opinion. > > How do the other RCSes handle this situation? Maybe we can learn > some ideas for a nice(r) UI there... Good question ... The equivalent in ClearCase was a "cleartool uncheckout": http://www-01.ibm.com/support/knowledgecenter/SSSH27_7.1.1/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_uncheckout.htm?cp=SSSH27_7.1.1%2F9-0-0-1-69 This has the -kee/p and -rm options on the command: > –kee/p > Preserves the contents of the checked-out version under a file-name of the > form element-name.keep > (or, to prevent name collisions, element-name.keep.1, element-name.keep.2, > and so on). > > –rm > Does not preserve the contents of the checked-out version. Thus, any edits > that had been made to > the checked-out version are lost. The default action is to prompt the user for what to do with the lost changes: > Cancel the checkout of file element util.c. $ cleartool uncheckout util.c Save private copy of "util.c"? [yes] no Checkout cancelled for "util.c". I guess the equivalent in git is the reset command: http://git-scm.com/docs/git-reset This seems to have three key options: > --hard > Resets the index and working tree. Any changes to tracked files in the > working tree since > are discarded. > > -merge > Resets the index and updates the files in the working tree that are different > between and > HEAD, but keeps those which are different between the index and working tree > (i.e. which have changes > which have not been added). If a file that is different between and > the index has unstaged > changes, reset is aborted. > > --keep > Resets index entries and updates files in the working tree that are different > between and > HEAD. If a file that is different between and HEAD has local > changes, reset is aborted. So _similar_ (but more quirky IMHO) operation to ClearCase. Dg. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
Re: Feature request: Save the old file when svn revert
Guten Tag OBones, am Dienstag, 21. Juli 2015 um 11:06 schrieben Sie: > I would very much prefer if this could be an option that is not enabled > by default. +1 I do revert frequently while merging branches and testing things and would hate it to have to additionally manually remove files which I don't need. "svn revert" reverts files, if I'm not sure I want that I copy things N times somewhere or else, but in 99% I'm sure. And the other 1% could as well be a mislead "rm -rf" in the wrong directory or a crashing HDD or whatever, wouldn't make any difference. I bet that the feature request is the result of a wrongly applied "svn revert", the frustration about that and I do understand that. But bad things happen all the time, so if one wants to have backups before reverting, this should be opt-in in my opinion. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Feature request: Save the old file when svn revert
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: 21 July 2015 16:09 > To: users@subversion.apache.org > Subject: Re: Feature request: Save the old file when svn revert > > > I would very much prefer if this could be an option that is not enabled > > by default. > > +1 > I think how ClearCase handles it is best: If you don't specify prompt. If you do specify then you're saying one way or the other which you explicitly want. Best of both worlds? Dg. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
RE: Feature request: Save the old file when svn revert
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: 21 July 2015 17:08 > To: users@subversion.apache.org > Subject: Re: Feature request: Save the old file when svn revert > > That way you still force millions of users to behave differently now > because one user made a mistake once. I don't see the point in why > revert should break backwards compatibility ... Backwards compatibility is a better (and valid) argument for not changing the behaviour of revert. I agree, for that reason, it should be an opt-in. Perhaps with a --keep option. (Hey look rational debate can change opinions on the Internet ... who knew ;) Dg. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
Re: Feature request: Save the old file when svn revert
On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
> Grierson, David wrote:
> >I completely understand that the action of sending to the Recycle Bin (in
> >TortoiseSVN) is very system specific.
> >
> >To simply rename the item being reverted as $item.$backupSuffix before then
> >restoring the pristine item is presumably not that system specific?
> >
> >Having this functionality in the base tool would then provide a benefit to
> >all users and not just those using a specific IDE.
> I would very much prefer if this could be an option that is not enabled by
> default. I mean, this would clutter the filesystem with many files that one
> would have to delete manually, especially when considering that some of us
> are using less than optimal filesystems when it comes down to lots of small
> files.
This seems to hint that the revert-backup item
possibly should *not* be placed in the same directory as the item,
but rather in an "alternate tree base"
(creating random similarly-named files next to each other in unexpected ways
seems just asking for trouble,
and lots of it - think build system mechanisms, other automatic
handling, ...).
Knee-jerk sample (hard-coded, non-elegant, read: day-to-day occurrence ;):
unit_test1.c
unit_test2.c
unit_test1.c.revert_backup
"cp -a unit_test* some_dir/"
"some_dir/tool unit_test*"
One might even implement this as a config option ("revert tree base directory"),
and if left unspecified/empty
svn could fall back to having .reverted files local,
or another mode might be to record this within the local .svn dirs.
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
Re: Feature request: Save the old file when svn revert
Guten Tag Grierson, David, am Dienstag, 21. Juli 2015 um 17:48 schrieben Sie: > If you don't specify prompt. > If you do specify then you're saying one way or the other which you > explicitly want. That way you still force millions of users to behave differently now because one user made a mistake once. I don't see the point in why revert should break backwards compatibility instead of providing opt-in, that could only be argued if creating backups is providing benefit to most users, which two of us are already doubting. Looking at git checkout, I don't see the requested behavior as well. I'll keep my vote for opt-in. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Feature request: Save the old file when svn revert
Seems to me that stashing the before-reverted copies could go into some
"recycle bin" / "trash" folder underneath the .svn folder at the root of
the working copy. And by default, the client could clean out files
time-stamped over a month old, so it doesn't perpetually grow. Cleanup
could happen on "commit" operations.
Then a new options could be added to the svn revert command. I'm thinking:
- revert --undo path/to-local/file # undoes the revert
- revert --list-undoable # lists all the available files with a revert
that can be undone
This has the advantages of not changing the existing semantics of the
revert operation, doesn't clutter up the directories of the working copy,
and self-cleans.
Eric.
On Tue, Jul 21, 2015 at 9:14 AM, Andreas Mohr wrote:
> On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
> > Grierson, David wrote:
> > >I completely understand that the action of sending to the Recycle Bin
> (in TortoiseSVN) is very system specific.
> > >
> > >To simply rename the item being reverted as $item.$backupSuffix before
> then restoring the pristine item is presumably not that system specific?
> > >
> > >Having this functionality in the base tool would then provide a benefit
> to all users and not just those using a specific IDE.
> > I would very much prefer if this could be an option that is not enabled
> by
> > default. I mean, this would clutter the filesystem with many files that
> one
> > would have to delete manually, especially when considering that some of
> us
> > are using less than optimal filesystems when it comes down to lots of
> small
> > files.
>
> This seems to hint that the revert-backup item
> possibly should *not* be placed in the same directory as the item,
> but rather in an "alternate tree base"
> (creating random similarly-named files next to each other in unexpected
> ways
> seems just asking for trouble,
> and lots of it - think build system mechanisms, other automatic
> handling, ...).
>
>
> Knee-jerk sample (hard-coded, non-elegant, read: day-to-day occurrence ;):
>
> unit_test1.c
> unit_test2.c
> unit_test1.c.revert_backup
>
> "cp -a unit_test* some_dir/"
> "some_dir/tool unit_test*"
>
>
> One might even implement this as a config option ("revert tree base
> directory"),
> and if left unspecified/empty
> svn could fall back to having .reverted files local,
> or another mode might be to record this within the local .svn dirs.
>
> Andreas Mohr
>
> --
> GNU/Linux. It's not the software that's free, it's you.
>
Re: Re: Sync-ing two SVN repositories
On Tue, Jul 21, 2015 at 3:58 AM, Andreas Stieger wrote: >> Even if you have two repositories that are identical to each other, one of >> them will need to be designated the "master", and that will be the one that >> all commits are made to. >> >> Subversion is a one-central-repository system. > > Unless of course one of the lesser known features is used: > Cross-repository copies and merges actually work (to not use the term > "supported"). Copies/moves will become additions, inter-revision history is > compessed and there is no merge tracking. See the three-agrument (copy or) > merge syntax "svn merge A@N A@M .", where A and "." refer to different > repositories. > > Not that it's recommended in the user's case, but it should be mentioned. > > Best approach in the svn space for Mani would be vendor branches based on the > information shared. Or investing in a genuine multi-master version of Subversion, which Wandisco sells. Simply spending some money instead of investing in hours of hacking and refactoring to make things work for your own special needs is sometimes well, more expensive in other ways.
