ASP Source Control 1

[Aidy680]

I think the post below is probably better suited to this forum:


Any of the good members of the Tek-Tips community, have any knowledge or opinions, on the best source control app, to harbour Classic ASP files?

Also, discussing deployment strategies, what are peoples thoughts on re-deploying the whole app (all files), when an update is made to just one file?


thread855-1717933: Classic ASP Source Control

 

[xwb]

I use git or svn depending on whether I have access to a central repository and whether I want version numbers. You have to have 3 ways of doing it. They are both free and quite easy to administer.

1) HTML only. For SVN, I use

<meta name="Id" conent="$Id$">

If the settings are set to svn:keywords=Id URL then it fills in the version number etc. Some people like the URL, some don't. git doesn't have this so you have to look at the tree map to see where you are. Alternatively between <!-- and -->

2) VBS, It will be

' $Id$

3) Javascript, it will be#pcode]

// $Id$
[code]

If you have include files that are read in by the asp code, then the headers will appear multiple times in the web page.  If you need a gui integrated with exporer, use tortisesvn or tortisegit.  Actually git has its own gui.  If you intend to use tortisegit, install git first because tortisegit looks for it.

MS has some source code control offerings but I've never used them.

I prefer svn to git because I can look at a file and tell whether I edited it last week or 10 weeks ago.  With git, I have to pop up git and  check where I am in the source tree.  With this sort of thing, I normally check in by feature.  When a feature is in, I do a checkin.

Remember to take a copy of all your sources first before you play with any of them.  If you get it wrong, they have the nasty habit of deleting everything and you are left without a source.  Play with a dummy project first: make sure you know what you are doing.

 

[Aidy680]

Thanks xwb. Much food for thought.

Where do you stand on my other point re: synching out of ALL files to PROD, when just one file has been updated?

The idea is that this allows you to maintain individual, separate versions. Is this common practice?

 

[xwb]

I'm not sure how this is done in GIT as I've only used it on noddy projects which were never branched.

For deployment in SVN, you just tag or branch the build. Unlike many source code control systems that employ databases etc, this is extremely efficient in SVN. It takes less than a second to tag/branch a build. Tagging and branching are the same except that they go into different directories. There is no need to maintain separate copies.

When you need to get a specific release just get it out by the tag or branch number.

Note that in svn and git, you checkin everything in one go. The files do not have individual revision numbers. 5 consecutive revision numbers of a file may be 20, 21, 27, 100, 2038.

 

[Aidy680]

Your last sentence is interesting.

When you say 'checkin everything', does that mean every file that constitutes your solution, regardless if they've been updated or not?

If that is the case, I cant help feeling it's unnecessary. Why checkin files you haven't updated?

Or have I got the wrong end of the stick?

Thanks for your continued responses.

 

[xwb]

Checking in is just for the files that have been modified. If you keep yourself disciplined and always checkin from the top level directory, then it is quite easy to track changes. It is also easy to pull out everything that has been modified when you are in a different sandbox.

 

[Aidy680]

Checking in is per individual file, but does the promotion to the next environment (DEV to UAT) constitute the whole solution, or just the file modified?

Hope I'm being clear here.

 

[xwb]

Say you have a tree that looks like this

+--project
   +-- css
       +-- xxx.css                 <-- modified
   +-- images
       +-- xyz.png                 <-- rev 100
       +-- abc.bmp                 <-- modified
   +-- javascript
       +-- splitdiv.js             <-- rev 205
       +-- slidemenu.js            <-- modified
       +-- jquery.js               <-- rev 20
   +-- index.asp                   <-- rev 20
   +-- products.asp                <-- rev 100
   +-- products_rsp.asp            <-- modified

On some systems, you'd have to check in each file individually. On git and svn, you checkin the project. That, in turn will pick up the modified files and check them in. Say you're using svn. It will tell you that this is checkin #206. All the modified files will be at revision 206. The other files will be at whatever revision they were at when you pulled out the project.

If you then go on several revisions and want to get back to this state, just get the project at revision 206.
[ul]
[li]It will get all the files at the revision they were at when you checked in rev 206.[/li]
[li]You will not see any new files introduced after 206.[/li]
[li]You will see files that were present at 206 and deleted at later revisions.[/li]
[/ul]

It is basically a snapshot of the whole project at that point in time. Some people check in at different directory levels. That often causes problems because the top level does not know about those so when you update the project, it may not get the latest files. If you always checkin at the project level, you won't get any problems.

 

[Aidy680]

Perfect. Exactly what i was after!

I can see the attraction in this but also some negatives.

For example, with an ASP project I would have to kick everyone out, to do a live release, as all the files would be replaced (albeit with the same thing). Currently, I'm far more surgical, and release just the one or two files (that have been modified), which doesn't necessitate the wholesale exit of the users.

What are your thoughts on this and how do you get round it?

 

[xwb]

You don't need to kick everyone out. Each person takes a copy. When they are ready to checkin, they do an update from the repository first. If there is a conflict, then they do a merge before checking in. This basically means only one person can have control of the tree at any time. Easiest way I've found is to allocate slots (2 hours or half day). Have a look at branching and merging in the link below. That talks about the command line version but it is even easier with tortoise (that is, if you are using Windows - for linux use rapidsvn).

SVN has the concept of lazy locking where more than one person can check out the file. The first one back in wins. The others have to merge. Developers will argue about this until the cows come home. Some prefer proper locking, some prefer lazy locking. If you've ever been caught out by someone who's locked a file then gone on holiday or left the project/company, then you'll understand why I prefer lazy locking. Anyway, in SVN, all is not lost because you can steal the lock.

The other alternative, of course, is to have everyone working in a different area so they don't all tread on each other's toes. Then anyone can checkin at any time.

With git, there is a completely different mindset. You have to merge repositories. I hate that but some people love it.

Have a look at SVN Book and Link.

The easiest way is to get a couple of VMs, set up a SVN repository in one and a GIT repository in the other and have a play. Nothing like hands on to find out what you like and what you don't like.

 

[xwb]

For a release, I normally extract everything from the repository, zip it up and send it out. How you do an install on a live system is something else. The easiest way, as you say, is to kick everyone off or do it early in the morning or late in the evening. If it is an international site, then you have to tell everyone that the system will be down between certain times. If the electricity board can do that, then you can too.

 

[Aidy680]

Thanks for all your time on this xwb, but I'm still not convinced that releasing into PROD, a load of files that haven't changed, into all manner of different directories, can be a good thing.

Kicking out users during business hours is also a step too far.

However, your time and opinions, are appreciated.

 

[xwb]

If you know when the last maintenance update was, you could use xcopy with the /d option to only copy files that were changed after a specified date. Then you don't have to move files individually and possibly to the wrong place or miss out files accidentally.

The automation is there but very often, we need to think about it and research it. Sometimes I do things the long winded way only to find 2-3 years later that I could have saved myself a lot of time if I'd researched the topic. The answer is normally some ancient DOS command that you haven't used since W95 days.

 

[Aidy680]

xwb - a followup question:

Is it entirely necessary, in your opinion, to get all the users out of the application, when releasing a new version?

If we're simply replacing like-for-like (files), wouldn't the transition be seamless?

Throwing out users is the default position normally, but I'm gonna get pushback here.

 

[xwb]

If it is the database, yes

If it is individual pages, not necessarily but that is just a personal opinion. I've tested it on a system with about 10 users but if you have 100s or 1000s of users hammering those pages, I don't really know what will happen.

 

[Aidy680]

It wont be the database, but it will be ALL the pages.

I'm currently just replacing individual pages - it's quite precise.

However, the idea of replacing all the pages, without kicking out the users, fills me with dread!

 

[xwb]

If you are replacing all pages, I'd kick all users out. It is just too risky.

 

[Aidy680]

Agreed xwb.

many thanks.