Everyone,
Thank you very much for your guidance and the wealth of knowledge you have provided. I'll make the recommendation not to squeeze everything into SVN.
Thanks,
Perry
-----Original Message-----
From: Eric Johnson [mailto:eric_at_tibco.com]
Sent: Friday, May 27, 2016 4:44 PM
To: Joseph Bruni; PERRY JENNINGS
Cc: users_at_subversion.apache.org
Subject: Re: SVN
On 5/27/16 12:57 PM, Joseph Bruni wrote:
>
> On May 26, 2016, at 10:09 PM, PERRY JENNINGS
> <PJENNINGS_at_FAMILYDOLLAR.com> wrote:
>
>> Family Dollar has implemented SVN and about sixty percent of projects
>> within the organization currently uses this repository to maintain
>> source code for object-oriented applications. However, the remaining
>> forty percent of source code within the organization cannot use SVN
>> because the code is for *non-object-oriented* applications ;
>>
Terminology is confusing me here. Object-oriented code has nothing to do with version control. Is what you really mean that you work with tools that deal with either monolithic project files, or smaller but opaque binary files?
>>
>> hence a single file, not a project needs to be checked in and out of
>> the repository. So my question is: Are you aware of a client that
>> could be used to checkout and checkin a single file to the SVN
>> repository and maintain the version number of the source code that is
>> checked in? If not, do you know if SVN has the single file checkout
>> and checkin feature?
>>
As a previous poster has mentioned, Subversion has "lock" functionality, so you can signal to people that changes are pending.
>
> We do the same thing for the database SQL scripts, stored procedure
> code, and various one-off Perl programs. Source control systems like
> SVN (or Git) don't really lend themselves directly to this type of object.
Why would you say that? I've used Subversion for all of the above. Works great. I'd be curious what issues you've run into?
> We do use SVN, but layered a lot of process on top of it to keep
> ourselves somewhat sane.
That's true of any source control system. You still need to manage the people and the workflows. Version control tools just make it easier to manage the shared built artifacts.
>
> I can imagine someone could build a nice single-file revision control
> system on top of SVN, but it would require a new type of client that
> would hide the directory revisioning from the user.
An alternate tool like Perforce can be used, as I recall, to actively prevent people from making changes to a file when it isn't "checked out". This is otherwise known as "pessimistic locking." If your user needs require pessimistic locking, then you should use a tool that does it. Probably not a good idea to squeeze everything into Subversion, if that's the case.
Eric.
----------------------------------------------------------------------
NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Received on 2016-06-03 19:12:47 CEST