[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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!

Regards,

Tom

From: Geoff Hoffman [mailto:ghoffman_at_cardinalpath.com]
Sent: Wednesday, June 15, 2011 7:05 PM
To: users_at_subversion.apache.org
Subject: Re: For Siebel

On Wed, Jun 15, 2011 at 3:06 PM, Mudumbai, Venkat <Venkat.Mudumbai_at_mercer.com<mailto:Venkat.Mudumbai_at_mercer.com>> wrote:
Hi,
We are planning to user SUBVERSION & TortoiseSVN for our Siebel Tools as a source control tools.
Siebel development using tools, as it is a a object based environment, where in we checkout and check in the several objects like applets,buscomps,picklist,links etc.

okay...

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:
svn log --verbose svn+ssh://path-to-server/svn/repos/sites/client

------------------------------------------------------------------------
r279 | fredjones | 2011-04-26 17:10:40 -0700 (Tue, 26 Apr 2011) | 1 line
Changed paths:
   M /sites/client/www/.htaccess
   M /sites/client/www/application/frontend/controllers/main.php
   M /sites/client/www/application/frontend/views/footer.php
   M /sites/client/www/application/frontend/views/header.php
   A /sites/client/www/application/frontend/views/menu.php
   D /sites/client/www/application/frontend/views/promotions.php

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:
> Siebel itself has a lock on the object created when an object is checkout.

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.
Received on 2011-06-16 01:49:20 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.