I was just verifying whether I understood you correctly. Going down
the road of working around this issue requires quite some effort. I
have an application which uses SVN to provide versioning for my data
(and provide collaboration possibilities) which is stored in files
with folder structures. During moving and renaming of those I ran into
those issues. Working around it would require that the application
locks the file in the repository and does the right unlocking before
commit (otherwise that would give issues).
Unfortunately my C knowledge is quite rusty as well, so providing a
patch for this is not achievable for me right now. I will log a defect
for this.
Regards,
Arjen Wisse
On Tue, Mar 29, 2011 at 6:13 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> Arjen Wisse wrote on Mon, Mar 28, 2011 at 09:51:43 +0200:
> > Hi Daniel,
> >
> > Thanks for responding to this issue.
> >
> > In fact what I was expecting is that when locking the file before
> > move, the lock being moved to the new location in the working copy as
> > well. However, that does not happen either (see defect
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3525).
> >
> > You suggested "lock the moved-from path", but how do I achieve that?
> > Does it mean that I require to lock it in the repository only?
> > Wouldn't that give a 'orphan' lock (I mean a lock only existing in the
> > repository, not in any working copy)?
> >
>
> Yes, it might result in the lock being orphan or being present in
> a different working copy. But I assumed your question was how to
> work around 'svn mv foo bar; svn lock bar' erroring out --- and
> I assumed the primary problem was to communicate the lock to others.
>
> Remember that you can always jump in and help us fix the issues...
>
> > Thanks & Regards,
> >
> > Arjen Wisse
> >
> >
> > On Sat, Mar 26, 2011 at 3:15 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > >
> > > But then once you commit --keep-locks the rename, you'll have to also
> > > move the lock from /f1/foo to /f2/foo, right?
> > >
> > > For that matter:
> > >
> > > % svn add iota
> > > % svn ci -mm iota
> > > % svn mv iota kappa
> > > % svn lock kappa
> > > % svn ci --keep-locks -m rename ./
> > >
> > > should also move the lock from iota to kappa. (currently it doesn't)
> > >
> > >
> > > This seems reasonable to me. (so, +1 to filing a feature request bug)
> > >
> > >
> > > And to answer your question: for now, lock the moved-from path.
> > >
> > >
> > > Arjen Wisse wrote on Wed, Mar 23, 2011 at 17:27:06 +0100:
> > > > Hi,
> > > >
> > > > Let's have the following folder/file structure:
> > > > * f1
> > > > ** test.txt
> > > >
> > > > (so the file 'test.txt' is part of folder 'f1').
> > > >
> > > > After renaming 'f1' to 'f2' (using svn rename) I get the following
> > > > error when executing:
> > > >
> > > > >svn lock f2/test.txt
> > > > svn: Path '/f2/test.txt' doesn't exist in HEAD revision
> > > >
> > > > Of course, it does not exist in the HEAD revision at that location,
> > > > because the folder is renamed. So, IMO it should lock the file
> > > > 'test.txt' in path '/f1/test.txt' in the repository as I did not
> > > > commit my rename yet. How can I ensure locking in this case?
> > > >
> > > > Regards,
> > > > Arjen Wisse
Received on 2011-03-29 11:25:07 CEST