Re: svn switch, touches files with svn:keywords
Nico Kadel-Garcia wrote on Tue, Sep 27, 2016 at 19:44:07 -0400: > If you switch the upstream repo for a software source repo, recompile. > It's the best way to make sure you've not left some datestamped file > inconsistencies that could mess with the system. Subversion supports both the "recompile from scratch after switch" workflow and the "recompile minimally after switch" workflow. You don't have to use the latter if you don't like it. Daniel
Implementing the Lock->Edit->Unlock cycle
Hello, all We are migrating to SVN from the dreaded SourceSafe and should like to retain, if only at the start, the exclusive check-out process, with the following *atomic* operations which should be performed as easily as possible: 1. lock and update, lest one might accidentally start editing an old version of some file. 2. commit and unlock. Can SVN be configured to have such operations, and how? We plan to use it mainly from the AnkhSVN plugin for Visual Studio, but I think the question belongs here.
Re: Implementing the Lock->Edit->Unlock cycle
Hi Anton, On 9/28/16 8:46 AM, Anton Shepelev wrote: Hello, all We are migrating to SVN from the dreaded SourceSafe and should like to retain, if only at the start, the exclusive check-out process, with the following *atomic* operations which should be performed as easily as possible: 1. lock and update, lest one might accidentally start editing an old version of some file. Subversion supports locks. However, it sounds like they do not work the way you want them to. Subversion's locks do not prevent anyone from editing files. They merely slow other people, besides the owner of the lock, from committing changes. "svn update" is your friend. Just encourage users to do updates before they start editing. Also, the lock-before-edit approach doesn't actually solve the problem of making sure users have the latest. My recollection from using VSS was that integration problems showed up more frequently, not less. I think this was from the illusion that I have the latest version of the file I want to edit (since I got the lock), so my files are probably all going to be consistent. In practice, other developers change APIs, and I only discover that by keeping current on the latest code changes. The Subversion approach quickly trains users to get the latest changes frequently. 2. commit and unlock. Commits and locks are independent. Can SVN be configured to have such operations, and how? I suspect you could tie yourself up into knots trying to write hook scripts that accomplish some of what you want, but by the time you get them working just the way you think you want them, you'll discover that you probably don't want them that way. Eric. We plan to use it mainly from the AnkhSVN plugin for Visual Studio, but I think the question belongs here.
Re: Implementing the Lock->Edit->Unlock cycle
On Wed, Sep 28, 2016 at 11:46 AM, Anton Shepelev wrote: > Hello, all > > We are migrating to SVN from the dreaded SourceSafe > and should like to retain, if only at the start, the > exclusive check-out process, with the following > *atomic* operations which should be performed as > easily as possible: > > 1. lock and update, > lest one might accidentally start editing an > old version of some file. > > 2. commit and unlock. > > Can SVN be configured to have such operations, and > how? > See these sections of the book: http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html and particularly this section: http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html#svn.advanced.locking.lock-communication Locking a file will not force an update to happen, but the lock itself is not held on any specific revision either. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: svn merge --reintegrate like diff
On Tue, Sep 27, 2016 at 10:12:28AM -0700, Alexey Neyman wrote:
> On 09/27/2016 01:46 AM, Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Mon, Sep 26, 2016 at 13:04:04 +0200:
> > > Maybe I'm missing something, but I don't understand why 'svn diff
> > > --old=TRUNK --new=BRANCH' would show you things that you previously
> > > merged from TRUNK to BRANCH. It should show exactly the content-wise
> > > difference between TRUNK and BRANCH, so if some content was merged
> > > from TRUNK to BRANCH, both should be identical on that point, and it
> > > shouldn't show up in 'diff'.
> > That command would also show changes made on trunk that have not yet been
> > merged to the branch. (E.g., if you ran it in on subversion's trunk and
> > 1.9.x branch, it would show -SVN_VER_MINOR 10\n +SVN_VER_MINOR 9\n.)
> >
> > The OP asked for the changes merge would do, which is approximately
> > --old=TRUNK@REV --new=BRANCH
> > where REV is the youngest revision of trunk merged to the branch.
> > ("Approximately" because this is inaccurate when cherry-picks or subtree
> > merges hapepned.)
> There's one more issue with these approaches. ReviewBoard can be smart about
> displaying the moved/copied files. However:
>
> - If one does 'svn merge --reintegrate', Subversion will copy new files from
> the branch unchanged, and 'svn diff' will not show them (and hence, RB won't
> either) - or, with --show-copies-as-adds, it will show them as being added
> anew. For the review purposes, it would be better if instead of copying the
> file from the branch unchanged, Subversion would perform the same move on
> the trunk and apply the textual changes.
> - If you do 'svn diff --old=... --new=...', I believe the copy-from
> information is lost from the diff completely - and ReviewBoard will show all
> the moved files as adds/deletes, not showing diffs either.
>
> For now, I am using the attached script to perform this task. The workflow
> is:
> 1. Perform a merge to trunk.
> 2. Run the script (which attempts to find the original location in trunk for
> every copied file and replay the move on trunk).
> 3. 'rbt post'.
>
> The script is not perfect; it only operates at file level - so if there are
> renamed directories, the files inside them end up in 'R +' status (replaced
> with history) and ReviewBoard shows a spurious deletion for this file, in
> addition to a move/copy with changes.
>
> Regards,
> Alexey.
>
Hi Alexey,
Could you compile an SVN client from trunk and try some merges with it,
and let me know how the merging of moves with the new conflict resolver
(which is still work-in-progress) is working out for you?
My goal is to make scripts like yours unnecessary.
The current implementation does not yet detect moves which happened
inside copies, but I hope to get that fixed before release.
Thanks,
Stefan
Re: Implementing the Lock->Edit->Unlock cycle
On 9/28/2016 5:46 PM, Anton Shepelev wrote: Hello, all We are migrating to SVN from the dreaded SourceSafe and should like to retain, if only at the start, the exclusive check-out process, with the following *atomic* operations which should be performed as easily as possible: 1. lock and update, lest one might accidentally start editing an old version of some file. 2. commit and unlock. Can SVN be configured to have such operations, and how? We plan to use it mainly from the AnkhSVN plugin for Visual Studio, but I think the question belongs here. I honestly suggest you drop that whole VSS concept of locking and unlocking files. In my current job I migrated us from VSS to SVN around 8 years ago. Those who only knew VSS before and got used to the problem of working with locked files had really heavy concerns about a system not relying on locks (and the potential problems with resolving/handling conflicts upon merges). It took them only around 2-3 days to realize that the way SVN works is way better than the lock/unlock style and all their concerns went away before the end of the week. That said: I really suggest you go the direct way and not use the lock/unlock workflow anymore. Maybe suggest to try it for a week at least and if it really causes concerns/problems in your case you can restore the lock/unlock process without much trouble at that point. If you still want to stay with locks, then yes, it's possible. Users can lock files (and therefore indicate that they are working on these), commit their change and unlock the file again. Note that out of the box SVN won't require a file to be locked before commit however (but if it is, you can't commit it without removing the lock first). You should be able to prevent commits without a prior lock however (via the pre-commit hook) and you could also automate unlocking of locked files upon commit (via the post-commit hook), if that's really something you need to do. As far as I know you can also ensure that a lock is only removed by an authorized user, via the pre-unlock-hook. -- Regards, Stefan Hett
