RE: For Siebel
From: Thomas Loy <Thomas.Loy_at_cbeyond.net>
Date: Wed, 15 Jun 2011 18:48:38 -0500
Subversion does have lock mechanisms, but they are not enabled by default. Although Siebel has it's lock mechanisms for sifs, I believe they are binary and you will want to implement locking in Subversion for them as well.
I sure wish I could get our Siebel teams to use SVN instead of exclusively depending on Siebel's lock mechanisms!
From: Geoff Hoffman [mailto:ghoffman_at_cardinalpath.com]
On Wed, Jun 15, 2011 at 3:06 PM, Mudumbai, Venkat <Venkat.Mudumbai_at_mercer.com<mailto:Venkat.Mudumbai_at_mercer.com>> wrote:
In my previous project we used VSS as the version control tools. In this when we check in a "sif" of the object checked in is created in the VSS Server.
I don't know what a "sif" is but SVN will store text and/or binary files under version control without any problems.
Siebel itself has a lock on the object created when an object is checkout. All we want is to know if the copy of the sif's whenever they are checked can be stored in Subversion, with details like who has checkedin, when it was cecked in.
Yes, that is exactly what it does. Here's some sample log output, gotten via command line:
Changed the .htaccess file and made the template modular.
With this, you can see on Apr 26, fredjones modified 4 files, added one, and deleted one
Also want to know how many versions of an object can be stored.
Limited only by hard drive space where your repo is stored.
Siebel is not a typical programming language.
There's no such thing as a typical programming language.
My question is : Can we use this SUBVERSION as a version control tools for our siebel tools. Please let me know as soon as possible as we are planning to install this s/w and do the set up as soon as possible.
I don't see why not.
Regarding this part:
The only thing is if you need Subversion to *not let Developer B checkout file X if Developer A already has it checked out*... I'm not sure it will do that. SVNt, by default, does not prevent checkout by Developer B. It expects you to instead merge manually, and expects you (the svn repository administrator, lead developer, etc) will do that part. If both Developer B and A checkout file X and they both modify it, the person who checks in first, gets their code into the repo without issue. The second developer probably will get a commit failure, with a message that his working copy is not up to date. He then has to merge his changes into the version in the repository, which is newer than what he checked out (because it was modified by the other developer's commit). It's not terribly difficult to manage merged code, but it is not a check-in-check-out system it is a version control system.
I hope that helps - good luck.
This is an archived mail posted to the Subversion Users mailing list.