Re: which version control supports file locking and who has it locked

[Doug Robinson]

The dichotomy is due to the expression of "knowing who is actually working
on a file".

I agree that if locking is used then (assuming nobody breaks the lock) you
know who will checkin next.  And, yes, agreed, when they check in is a
social issue.

However, you really don't know who is working on the file.  This may all
seem meta-physical but I've seen requirements for SCM systems where it
really was necessary to know exactly who was actually working on the file
in their sandbox.  None of the discussed SCMs here support those semantics.

On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
wrote:

> Doug,
>
> Doug Robinson wrote:
> > To be more precise, you can know who, in the past, has made changes to
> files and
> > checked those change into the repository.  You cannot know who has made
> changes
> > in their working copy and has not yet checked them back into the
> repository (they
> > may never do so).
>
> I am not sure why you would introduce this dichotomy here, it is
> irrelevant. OP asked for locking support. Subversion supports locking, lock
> hinting (svn:needs-lock), lock communication/discovery (display of who,
> when and why). In the cli, hooks and GUI clients. Whether or not actual
> changes were done in any working copy is irrelevant, and a delay in
> submission a mere social/project problem.
>
> > To know who is actually working on a file requires a level of
> integration that is not
> > found in SVN, Git or CVS.  I have a vague recollection of an SCM that
> did enable
> > such information but I'm not remembering which one it is at the moment.
>
> Rather, if the project policy is such that locking is required, it should
> be implemented accordingly. lock-modify-unlock for the whole project is a
> supported option, albeit not a commonly used one.
>
> Andreas
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: which version control supports file locking and who has it locked

[Doug Robinson]

Brane:

You're right!  ClearCase with dynamic views would provide that data (files
could not be modified unless checked out and the checkouts left markers in
the database).  You could even see "who" from other replicas (assuming
proper synchronization).

Agreed: you could not see what changes they were making unless you had
access to their view.

Thank you.

Doug

On Tue, Jun 7, 2016 at 9:54 AM, Branko Čibej  wrote:

> On 06.06.2016 15:47, Doug Robinson wrote:
> > Andreas:
> >
> > On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger
> > mailto:andreas.stie...@gmx.de>> wrote:
> >
> > > or knowing who is actually working on a file.
> >
> > Incorrect, this is shown in both TortoiseSVN and svn cli.
> >
> >
> > To be more precise, you can know who, in the past, has made changes to
> > files _and
> > _checked those change into the repository.  You cannot know who has
> > made changes
> > in their working copy and has not yet checked them back into the
> > repository (they
> > may never do so).
> >
> > To know who is actually working on a file requires a level of
> > integration that is not
> > found in SVN, Git or CVS.  I have a vague recollection of an SCM that
> > did enable
> > such information but I'm not remembering which one it is at the moment.
>
>
> I believe ClearCase with dynamic views could do that, but even that
> couldn't show diffs from someone else's view (since while the view was
> stored on the server, the actual changes were only stored locally on the
> client).
>
> -- Brane
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: which version control supports file locking and who has it locked

[Doug Robinson]

Jan:

Thanks for the note about CVS watches.  I was unaware of that feature.
Interesting.

I agree, such a feature would tend to go directly against the requirements
for a DVCS.

Doug

On Mon, Jun 6, 2016 at 10:19 AM, Jan Keirse  wrote:

>
> On Mon, Jun 6, 2016 at 3:47 PM, Doug Robinson 
> wrote:
>
>> Andreas:
>>
>> On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger 
>> wrote:
>>
>>> > or knowing who is actually working on a file.
>>>
>>> Incorrect, this is shown in both TortoiseSVN and svn cli.
>>>
>>
>> To be more precise, you can know who, in the past, has made changes to
>> files
>> *and*checked those change into the repository.  You cannot know who has
>> made changes
>> in their working copy and has not yet checked them back into the
>> repository (they
>> may never do so).
>>
>> To know who is actually working on a file requires a level of integration
>> that is not
>> found in SVN, Git or CVS.  I have a vague recollection of an SCM that did
>> enable
>> such information but I'm not remembering which one it is at the moment.
>>
>>
> ​Whether it is possible to know who is working on a file is not the same
> as what the changes made so far in the working copy are. This IS possible
> without much problems with at least CVS with minor effort: By setting a
> watch on a module alle files in that module are checked out read only.
> Before changing a file one uses the CVS edit command, that takes care of
> making the file read/write and keep track of who edits what. I'm not
> entirely sure if this is the behavior the SVN implementation supports.
> Off course it is possible to ignore the read-only flag and use operating
> system tools to overwrite them without first using the edit command, but as
> long as everyone involved knows the tools this works very well and
> accidents are unlikely because files are read-only by default.  The only
> problem might be you only find out you had not yet edited a file the first
> time you save changes and fixing that requires either a habit change (the
> new habit being either first edit or save early, save often, which is a
> good idea anyway)  or a simple trigger in your IDE.
>
> We have used this CVS feature with success in the past for source files
> that require 'exclusive edits' because merging was next-to-impossible (as
> would be the case for many binary file.) When we migrated to Subversion for
> unrelated reasons I couldn't quite get it to work like we wanted (if I
> remember correctly taking a lock was more on a voluntary basis, you
> couldn't make the files read-only by default and therefore accidentally
> forgetting to lock was far more likely.) So I ended up implementing an edit
> trigger in the IDE to handle this, which works fine for our use case but
> might not be possible in other setups.
>
> I don't see how it could be implemented in a DVCS though, at least not
> without a non-distributed part added to it which defeats at least some of
> its purpose.
>
> As for other systems supporting this functionality, to answer the original
> question: At least Microsoft TFS and Roundtable TSMS (a platform intended
> specifically for OpenEdge ABL) support it to some extent. This being said,
> I wouldn't pick any of these or CVS over something like Subversion, GIT or
> Mercurial if I were to make the choice.
>
>  DISCLAIMER 
>
> http://www.tvh.com/glob/en/email-disclaimer
>
> "This message is delivered to all addressees subject to the conditions
> set forth in the attached disclaimer, which is an integral part of this
> message."
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: which version control supports file locking and who has it locked

[Doug Robinson]

Agreed on ClearCase.

As for locking, it is normally considered "absolutely essential" for files
that "do not merge".  Think checking in binaries.  Or ugly generated XML
files (using unhappy algorithms).  Pick your favorite non-merge-capable
file type(s).  The point is to prevent multiple people from changing them
at the same time - or at least enable them to attempt to coordinate the
changes so nothing is lost.

On Wed, Jun 8, 2016 at 9:42 AM, Boris Epstein  wrote:

> I believe ClearCase does that.
>
> If I may ask, why is it important? I believe CVS, SVN, Git and many others
> allow to get your edits in via merging mechanisms of various kinds, so I am
> just curious what the use case scenario would be where locking is
> absolutely essential.
>
> Cheers,
>
> Boris.
>
>
> On Mon, Jun 6, 2016 at 10:19 AM, Jan Keirse  wrote:
>
>>
>> On Mon, Jun 6, 2016 at 3:47 PM, Doug Robinson > > wrote:
>>
>>> Andreas:
>>>
>>> On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger 
>>> wrote:
>>>
 > or knowing who is actually working on a file.

 Incorrect, this is shown in both TortoiseSVN and svn cli.

>>>
>>> To be more precise, you can know who, in the past, has made changes to
>>> files
>>> *and*checked those change into the repository.  You cannot know who has
>>> made changes
>>> in their working copy and has not yet checked them back into the
>>> repository (they
>>> may never do so).
>>>
>>> To know who is actually working on a file requires a level of
>>> integration that is not
>>> found in SVN, Git or CVS.  I have a vague recollection of an SCM that
>>> did enable
>>> such information but I'm not remembering which one it is at the moment.
>>>
>>>
>> ​Whether it is possible to know who is working on a file is not the same
>> as what the changes made so far in the working copy are. This IS possible
>> without much problems with at least CVS with minor effort: By setting a
>> watch on a module alle files in that module are checked out read only.
>> Before changing a file one uses the CVS edit command, that takes care of
>> making the file read/write and keep track of who edits what. I'm not
>> entirely sure if this is the behavior the SVN implementation supports.
>> Off course it is possible to ignore the read-only flag and use operating
>> system tools to overwrite them without first using the edit command, but as
>> long as everyone involved knows the tools this works very well and
>> accidents are unlikely because files are read-only by default.  The only
>> problem might be you only find out you had not yet edited a file the first
>> time you save changes and fixing that requires either a habit change (the
>> new habit being either first edit or save early, save often, which is a
>> good idea anyway)  or a simple trigger in your IDE.
>>
>> We have used this CVS feature with success in the past for source files
>> that require 'exclusive edits' because merging was next-to-impossible (as
>> would be the case for many binary file.) When we migrated to Subversion for
>> unrelated reasons I couldn't quite get it to work like we wanted (if I
>> remember correctly taking a lock was more on a voluntary basis, you
>> couldn't make the files read-only by default and therefore accidentally
>> forgetting to lock was far more likely.) So I ended up implementing an edit
>> trigger in the IDE to handle this, which works fine for our use case but
>> might not be possible in other setups.
>>
>> I don't see how it could be implemented in a DVCS though, at least not
>> without a non-distributed part added to it which defeats at least some of
>> its purpose.
>>
>> As for other systems supporting this functionality, to answer the
>> original question: At least Microsoft TFS and Roundtable TSMS (a platform
>> intended specifically for OpenEdge ABL) support it to some extent. This
>> being said, I wouldn't pick any of these or CVS over something like
>> Subversion, GIT or Mercurial if I were to make the choice.
>>
>>  DISCLAIMER 
>>
>> http://www.tvh.com/glob/en/email-disclaimer
>>
>> "This message is delivered to all addressees subject to the conditions
>> set forth in the attached disclaimer, which is an integral part of this
>> message."
>>
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the

Re: Creating and Verifying a Reliable backup

[Doug Robinson]

At least one problem with "svnsync" is that it, by design, does not
propagate the locks.  So a sync'd repo cannot replace the sync'd-from
repository without losing all of the locks.

On Thu, Jun 2, 2016 at 9:28 AM, Daniel Shahaf 
wrote:

> Michael Schwager wrote on Wed, Jun 01, 2016 at 09:58:18 -0500:
> > We are very paranoid about our Subversion repo, notwithstanding the fact
> > that the previous sysadmin didn't back it up. But that's another story.
> Now
> > I'm here at my job, I've inherited the repo admin duties, and I want to
> > back it up reliably. If we lose it, we're all out of work.
> >
> > My question is: How do I back it up reliably,
>
> I would recommend svnsync.  It should be more robust than 'hotcopy' due
> to the way they are implemented: 'svnsync' wraps 'log' and 'commit'
> while 'hotcopy' is implemented by a dedicated codepath which bypasses
> the usual filesystem-internal reading/writing APIs.
>
> Cheers,
>
> Daniel
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: which version control supports file locking and who has it locked

[Mark McKeown]

Hi Doug,
   So if I remember correctly p4 supports this, when you "p4
edit" a file it will tell you if anyone else has already done "p4 edit" on
the file.

cheers
Mark

On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson 
wrote:

> The dichotomy is due to the expression of "knowing who is actually
> working on a file".
>
> I agree that if locking is used then (assuming nobody breaks the lock) you
> know who will checkin next.  And, yes, agreed, when they check in is a
> social issue.
>
> However, you really don't know who is working on the file.  This may all
> seem meta-physical but I've seen requirements for SCM systems where it
> really was necessary to know exactly who was actually working on the file
> in their sandbox.  None of the discussed SCMs here support those semantics.
>
> On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
> wrote:
>
>> Doug,
>>
>> Doug Robinson wrote:
>> > To be more precise, you can know who, in the past, has made changes to
>> files and
>> > checked those change into the repository.  You cannot know who has made
>> changes
>> > in their working copy and has not yet checked them back into the
>> repository (they
>> > may never do so).
>>
>> I am not sure why you would introduce this dichotomy here, it is
>> irrelevant. OP asked for locking support. Subversion supports locking, lock
>> hinting (svn:needs-lock), lock communication/discovery (display of who,
>> when and why). In the cli, hooks and GUI clients. Whether or not actual
>> changes were done in any working copy is irrelevant, and a delay in
>> submission a mere social/project problem.
>>
>> > To know who is actually working on a file requires a level of
>> integration that is not
>> > found in SVN, Git or CVS.  I have a vague recollection of an SCM that
>> did enable
>> > such information but I'm not remembering which one it is at the moment.
>>
>> Rather, if the project policy is such that locking is required, it should
>> be implemented accordingly. lock-modify-unlock for the whole project is a
>> supported option, albeit not a commonly used one.
>>
>> Andreas
>>
>
>
>
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com
>
> *www.wandisco.com *
>
>
> Learn how WANdisco Fusion solves Hadoop data protection and scalability
> challenges 
>
> Listed on the London Stock Exchange: WAND
> 
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
> PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its
> subsidiaries, ("WANdisco") does not waive any confidentiality or
> privilege.  If you are not the intended recipient, please notify us
> immediately and destroy the message without disclosing its contents to
> anyone.  Any distribution, use or copying of this e-mail or the information
> it contains by other than an intended recipient is unauthorized.  The views
> and opinions expressed in this e-mail message are the author's own and may
> not reflect the views and opinions of WANdisco, unless the author is
> authorized by WANdisco to express such views or opinions on its behalf.
> All email sent to or from this address is subject to electronic storage and
> review by WANdisco.  Although WANdisco operates anti-virus programs, it
> does not accept responsibility for any damage whatsoever caused by viruses
> being passed.
>

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: which version control supports file locking and who has it locked

[Doug Robinson]

Mark:

Nice.  And ClearCase with Dynamic Views as Brane reminded me.

Doug

On Fri, Jun 10, 2016 at 4:36 PM, Mark McKeown 
wrote:

> Hi Doug,
>So if I remember correctly p4 supports this, when you "p4
> edit" a file it will tell you if anyone else has already done "p4 edit" on
> the file.
>
> cheers
> Mark
>
> On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson  > wrote:
>
>> The dichotomy is due to the expression of "knowing who is actually
>> working on a file".
>>
>> I agree that if locking is used then (assuming nobody breaks the lock)
>> you know who will checkin next.  And, yes, agreed, when they check in is a
>> social issue.
>>
>> However, you really don't know who is working on the file.  This may all
>> seem meta-physical but I've seen requirements for SCM systems where it
>> really was necessary to know exactly who was actually working on the file
>> in their sandbox.  None of the discussed SCMs here support those semantics.
>>
>> On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
>> wrote:
>>
>>> Doug,
>>>
>>> Doug Robinson wrote:
>>> > To be more precise, you can know who, in the past, has made changes to
>>> files and
>>> > checked those change into the repository.  You cannot know who has
>>> made changes
>>> > in their working copy and has not yet checked them back into the
>>> repository (they
>>> > may never do so).
>>>
>>> I am not sure why you would introduce this dichotomy here, it is
>>> irrelevant. OP asked for locking support. Subversion supports locking, lock
>>> hinting (svn:needs-lock), lock communication/discovery (display of who,
>>> when and why). In the cli, hooks and GUI clients. Whether or not actual
>>> changes were done in any working copy is irrelevant, and a delay in
>>> submission a mere social/project problem.
>>>
>>> > To know who is actually working on a file requires a level of
>>> integration that is not
>>> > found in SVN, Git or CVS.  I have a vague recollection of an SCM that
>>> did enable
>>> > such information but I'm not remembering which one it is at the moment.
>>>
>>> Rather, if the project policy is such that locking is required, it
>>> should be implemented accordingly. lock-modify-unlock for the whole project
>>> is a supported option, albeit not a commonly used one.
>>>
>>> Andreas
>>>
>>
>>
>>
>> --
>> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>>
>> *T *925-396-1125
>> *E* doug.robin...@wandisco.com
>>
>> *www.wandisco.com *
>>
>>
>> Learn how WANdisco Fusion solves Hadoop data protection and scalability
>> challenges 
>>
>> Listed on the London Stock Exchange: WAND
>> 
>>
>> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY
>> BE PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its
>> subsidiaries, ("WANdisco") does not waive any confidentiality or
>> privilege.  If you are not the intended recipient, please notify us
>> immediately and destroy the message without disclosing its contents to
>> anyone.  Any distribution, use or copying of this e-mail or the information
>> it contains by other than an intended recipient is unauthorized.  The views
>> and opinions expressed in this e-mail message are the author's own and may
>> not reflect the views and opinions of WANdisco, unless the author is
>> authorized by WANdisco to express such views or opinions on its behalf.
>> All email sent to or from this address is subject to electronic storage and
>> review by WANdisco.  Although WANdisco operates anti-virus programs, it
>> does not accept responsibility for any damage whatsoever caused by viruses
>> being passed.
>>
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever

Question on info -r committed for file externals

[Dan Ellis]

Hi,

I've noticed some differing behavior when using file externals and svn info
-r committed.  I'm not sure what the expected behavior should be... hoping
to see what the masses think.  I'm running svn 1.8.13 on Windows 7.

When I first create a file external and perform an update, the "svn info -r
committed foo.c" provides a response.  After an additional update, with no
changes to the working copy (or repo), the "svn info -r committed foo.c"
gives an error of 'foo.c' has no committed revision.  It appears the update
which adds the external creates a different state then the updating of an
already file external.  I'm fine with the behavior, but curious about about
why and perhaps there could be other latent issues.

Thanks,
Dan

Here's a simple batch file to reproduce:

svnadmin create c:\project_files\test_repo
svn checkout file:///c:/project_files/test_repo c:\project_files\test_wc
cd c:\project_files\test_wc
echo test > foo.c
svn add foo.c
svn commit foo.c -m "test commit"
svn update
svn ps svn:externals "foo_external.c
file:///c:/project_files/test_repo/foo.c" .
svn update
svn info -r committed foo_external.c
rem This works
svn update
svn info -r committed foo_external.c
rem This does not


And a snippet of the output

c:\Project_files\test_wc>svn ps svn:externals "foo_external.c
file:///c:/project_files/test_repo/foo.c" .
property 'svn:externals' set on '.'

* First update does the add and appears to allow an info request *
c:\Project_files\test_wc>svn update
Updating '.':

Fetching external item into 'foo_external.c':
Afoo_external.c
Updated external to revision 1.

At revision 1.

c:\Project_files\test_wc>svn info -r committed foo_external.c
Path: foo.c
Name: foo.c
URL: file:///C:/project_files/test_repo/foo.c
Relative URL: ^/foo.c
Repository Root: file:///C:/project_files/test_repo
Repository UUID: e30464d6-ebeb-3146-b634-d99b5dbdd120
Revision: 1
Node Kind: file
Last Changed Author: me
Last Changed Rev: 1
Last Changed Date: 2016-06-10 15:31:27 -0700 (Fri, 10 Jun 2016)


* Second update with no changes whatsoever appears to bail *
c:\Project_files\test_wc>svn update
Updating '.':

Fetching external item into 'foo_external.c':
External at revision 1.

At revision 1.

c:\Project_files\test_wc>svn info -r committed foo_external.c
svn: E195002: Path 'C:\Project_files\test_wc\foo_external.c' has no
committed revision