Re: Feature request: Save the old file when svn revert
On Thu, Jul 23, 2015 at 7:16 PM Grierson, David david.grier...@sky.uk wrote: -Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: 23 July 2015 07:59 To: users@subversion.apache.org Subject: Re: Feature request: Save the old file when svn revert On 22.07.2015 15:51, Bert Huijben wrote: -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: woensdag 22 juli 2015 13:43 To: Markus Schaber m.scha...@codesys.com Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛 What we really want here is svn stash, i.e., an equivalent to git stash. In other words, I would not consider changing how svn revert works; instead, I'd like to design a new working copy feature that does more useful stuff than just saving away local modifications on revert. Since any such saving would require a working copy format change to be even remotely useful, we may as well consider introducing whole-hawg working copy state management. Guys, I think you're needlessly over-complicating things. Genuinely - what's wrong with just saving the modified item to a new name (e.g. $item.reverted)? Okay - you /might/ end up with files cluttering up a working copy ... so you remove them if they're troubling you. They won't have been created unless you explicitly opted-in to have the revert save the modifications. If you actually wanted to keep them then they're not going to trouble you If users have to opt-in, and remember to have these modifications saved, they're going to forget, and the data will be lost anyway. I would recommend doing copy foo foo.bak svn revert foo or svn diff . ..\diff.patch svn revert -R . Both scenarios saves a copy of the changes, and then revert, without a coding change. Cheers, Daniel B.
Re: Feature request: Save the old file when svn revert
On 22.07.2015 15:51, Bert Huijben wrote: -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: woensdag 22 juli 2015 13:43 To: Markus Schaber m.scha...@codesys.com Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛 暁冬 neoedm...@gmail.com; users@subversion.apache.org Subject: Re: Feature request: Save the old file when svn revert Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +: 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. Note that 'svn revert' without further arguments does nothing and errors out; you must name explicitly what will be reverted. (Even with '-R' you still need to specify a target directory.) How do the other RCSes handle this situation? Maybe we can learn some ideas for a nice(r) UI there... In Git, if you add a file to the index, you can generally 'cat-file blob' it out of there for a while later if you know its hash (eg, if you have the header of a diff of that file, as headers mention the hash). Ditto for local commits, you can get them from the reflog for a while later (until a garbage collection pass). Adding it to the index, is usually done by something like commit. In that case I don't think you really need to stash the actual file locally, as you can just get it with 'svn cat' (probably after finding some revision with svn log) The local version of the file might have local changes though... If you would store that one in the pristine store, it would have some sha-1 hash... But I doubt the user would know that hash, and without that he/she would be unable to retrieve it, unless we build some UI. In that case I would start by looking at the UI. What we really want here is svn stash, i.e., an equivalent to git stash. In other words, I would not consider changing how svn revert works; instead, I'd like to design a new working copy feature that does more useful stuff than just saving away local modifications on revert. Since any such saving would require a working copy format change to be even remotely useful, we may as well consider introducing whole-hawg working copy state management. -- Brane
Re: Feature request: Save the old file when svn revert
On 23.07.2015 11:15, Grierson, David wrote: -Original Message- From: Branko Čibej [mailto:br...@wandisco.com] Sent: 23 July 2015 07:59 To: users@subversion.apache.org Subject: Re: Feature request: Save the old file when svn revert On 22.07.2015 15:51, Bert Huijben wrote: -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: woensdag 22 juli 2015 13:43 To: Markus Schaber m.scha...@codesys.com Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛 What we really want here is svn stash, i.e., an equivalent to git stash. In other words, I would not consider changing how svn revert works; instead, I'd like to design a new working copy feature that does more useful stuff than just saving away local modifications on revert. Since any such saving would require a working copy format change to be even remotely useful, we may as well consider introducing whole-hawg working copy state management. Guys, I think you're needlessly over-complicating things. Genuinely - what's wrong with just saving the modified item to a new name (e.g. $item.reverted)? Okay - you /might/ end up with files cluttering up a working copy ... so you remove them if they're troubling you. You've probably never been at the receiving end of user complaints, have you. :) They won't have been created unless you explicitly opted-in to have the revert save the modifications. If you actually wanted to keep them then they're not going to trouble you. Any new conditional feature adds another dimension to compatibility testing and code complexity. In other words, maintenance costs a lot more than development in this case, for a feature that's doubtful at best. Sure this doesn't handle directory reverts but it's an improvement without any major change to the behaviour of the revert command, no change to the format of working copies or anything else like that. Surely some simple benefit is better than ending up with a feature that's going to take a massive amount of effort to develop and test? I for one don't intend to support adding more short-cuts and hacks to the code. There are already too many of them. You have to consider that once we add your proposed feature, we have to maintain it indefinitely, even if, in the meantime, we come up with a better solution. As noted elsewhere, 'svn revert' by itself does nothing; you have to explicitly tell it what to revert. We can't make a foolproof command-line client, so why try? Are you going to complain to the bash developers because 'rm -fr * .o' doesn't do what you intended? -- Brane
RE: Feature request: Save the old file when svn revert
-Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: woensdag 22 juli 2015 13:43 To: Markus Schaber m.scha...@codesys.com Cc: Grierson, David david.grier...@sky.uk; d...@subversion.apache.org; 牛 暁冬 neoedm...@gmail.com; users@subversion.apache.org Subject: Re: Feature request: Save the old file when svn revert Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +: 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. Note that 'svn revert' without further arguments does nothing and errors out; you must name explicitly what will be reverted. (Even with '-R' you still need to specify a target directory.) How do the other RCSes handle this situation? Maybe we can learn some ideas for a nice(r) UI there... In Git, if you add a file to the index, you can generally 'cat-file blob' it out of there for a while later if you know its hash (eg, if you have the header of a diff of that file, as headers mention the hash). Ditto for local commits, you can get them from the reflog for a while later (until a garbage collection pass). Adding it to the index, is usually done by something like commit. In that case I don't think you really need to stash the actual file locally, as you can just get it with 'svn cat' (probably after finding some revision with svn log) The local version of the file might have local changes though... If you would store that one in the pristine store, it would have some sha-1 hash... But I doubt the user would know that hash, and without that he/she would be unable to retrieve it, unless we build some UI. In that case I would start by looking at the UI. Bert
Re: Feature request: Save the old file when svn revert
On 21 July 2015 at 11:38, Andreas Stieger andreas.stie...@gmx.de wrote: 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. I think best solution is to move reverted files to Recycle Bin if it present on platform. Many platforms seems to have Recycle Bin concept these days: Recycle Bin on Windows, ~/.Trash on Ubuntu and Trash on Mac OS [1] [1] http://www.hardcoded.net/articles/send-files-to-trash-on-all-platforms -- Ivan Zhakov
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
-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
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
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
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 a...@lisas.de 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: 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
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
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.
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 commit are discarded. -merge Resets the index and updates the files in the working tree that are different between commit 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 commit and the index has unstaged changes, reset is aborted. --keep Resets index entries and updates files in the working tree that are different between commit and HEAD. If a file that is different between commit 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.
