RE: svn:externals and specific revisions

I tried to convert this into usable plain text, but failed, so it's
coming through in HTML format. I hope this does not cause any issues.
 
In my infinite impatience, I decided to toy with this myself, since I
already had everything set up for it. Here are my notes from that
experience:
 
When I specify a revision in the externals property, that revision will
be pulled down on update. However, users are permitted to commit
changes if the files being changed do not have newer versions. After
committing these changes, if they "update", those changes will be
removed from the workspace - causing much confusion.

Additionally, the proper specified version is only pulled down when the
"update" occurs at the folder that has the svn:external property. If
the user executes "update" in the work folder of the external reference,
the newest revision is retrieved - causing much confusion.

Conclusion

This feature should be used with extreme caution, and any externally
referenced items should be snapshots that are locked-down via security
settings. This will ensure that the desired revision is always
referenced and no developers can commit changes. Advanced senior
developers and architects can make use of this sharing feature to
extreme benefit with the proper dosage of finesse.

 
So, I think this feature leaves quite a bit of room for people to really
f*#k <mailto:f*@k> things up bad. I have a few feature requests.
1. When a revision is specified in the property, the referenced files
should be read-only (no commits) reglardless of the users' regular
security privileges.
 
2. I notice that when switching to a branch that lacks the svn:externals
defn, the files are left in the workspace even though the workspace
files (.svn) are removed. When switching back, errors occur because
it's trying to put files down and they're already in place.
 
3. When workspace files are created due to the svn:externals definition,
those subfolders should also be constrained by the definition. When an
update is executed, it should get the specific revision defined in the
property, which is attached to a parent folder.
 
4. An indicator should be available for clients like Tortoise and Ankh
that can be used to give a visual cue that particular files or folders
are external references.
 
4a. Even better, an ability to show the repository path with version
would be nice. For example, if that text is included in one of the .svn
files, a client can add a feature to show it to a user on mouse hover.
In fact, that would be nice for non-external folders, too. This would
eliminate the need for a developer to do extra work to verify which
codeline is being modified (say, after being away for a 4 hour meeting).
 

--
David
________________________________
	From: Hari Kodungallur [mailto:hkodungallur@gmail.com] 
	Sent: Friday, September 14, 2007 1:28 PM
	To: Bicking, David (HHoldings, IT)
	Cc: users@subversion.tigris.org
	Subject: Re: svn:externals and specific revisions
	
	
	On 9/14/07, Bicking, David (HHoldings, IT)
<David.Bicking@thehartford.com> wrote: 
		I like svn:externals.  I have a question, and I don't
see the answer
		 
		 
	If I understand your question correctly, you are asking what
happens if the external is set to a particular revision. For example: if
the external was
	  mydir  -r OldRevision http://myurl/mydir
	 
	In that case, it should work exactly like when you checkout a
particular revision of any URL. If you don't checkout the HEAD and
instead checkout an older revision and then try to commit any changes,
the svn client will give you an out-of-date error. It will not let you
commit until you update the files to the latest. Same thing should hold
good for directories checked out as external. 
	 
	If I misunderstood your question, can you please elaborate?
	 
	Thanks,
	-Hari Kodungallur
	 
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************