Collaborative Workflow tips

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Rochey

Well-known member
White Market Member
Joined
Jul 2, 2004
Messages
2,697
Location
Dallas, TX - Formerly UK
Gents, (and Ladies if there are any here these days)

can those of you who work in multiple-developer-same-project environments describe your current workflow and setup?

e.g. Our current strategy (expat audio) involves a few different tools

- PCB and Schematic development on individual PCs
- component management on Aligni.com
- Wiki for shared notes.
- Office-Live for shared office documents shared by project.


I'd like to move to a "shared drive" type design flow for schematics and PCB's, continue to use Aligni for component management, and somehow use the shared drive setup for the wiki and shared documents.

How do the pro's do it in the real world? What file structure do they use to keep schematics, libraries and project notes separate, yet linked?

Any books I should read on this topic?

cheers

R
 
[quote author="Rochey"]Gents, (and Ladies if there are any here these days)

can those of you who work in multiple-developer-same-project environments describe your current workflow and setup?

e.g. Our current strategy (expat audio) involves a few different tools

- PCB and Schematic development on individual PCs
- component management on Aligni.com
- Wiki for shared notes.
- Office-Live for shared office documents shared by project.


I'd like to move to a "shared drive" type design flow for schematics and PCB's, continue to use Aligni for component management, and somehow use the shared drive setup for the wiki and shared documents.

How do the pro's do it in the real world? What file structure do they use to keep schematics, libraries and project notes separate, yet linked?

Any books I should read on this topic?

cheers

R[/quote]

How ironic, im looking to get going a user/assembly manual for the Green Pre and possibly something else which I havent decided on yet.

So, please give me more info on "sharing" notes and this "network drive" you are speaking of.

PM me if you want or email me at [email protected]
 
ENS,

most manuals etc work well on a Wiki. That way, people can collaboratively add, edit and remove text from it.

Looks for online mediawiki hosting.

/R
 
I would set something up like this:

1 server somewhere (preferably in an air conditioned colo) that you can SSH into via terminal.

each collaborator would have a "work" folder on there local machine that gets backed up to the server whenever a script is run. Set up the script as a cron job, say ever day at 5pm it will back up.

setup rsync to rotate saved files every 7 days.



#!/bin/sh

# This script does personal backups to a rsync backup server. You will end up
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# [email protected] o m

# directory to backup
BDIR=/home/$USER

# excludes file - this contains a wildcard pattern per line of files to exclude
EXCLUDES=$HOME/cron/excludes

# the name of the backup machine
BSERVER=owl

# your password on the backup server
export RSYNC_PASSWORD=XXXXXX


########################################################################

BACKUPDIR=`date +%A`
OPTS="--force --ignore-errors --delete-excluded --exclude-from=$EXCLUDES
--delete --backup --backup-dir=/$BACKUPDIR -a"

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin

# the following line clears the last weeks incremental directory
[ -d $HOME/emptydir ] || mkdir $HOME/emptydir
rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/
rmdir $HOME/emptydir

# now the actual transfer
rsync $OPTS $BDIR $BSERVER::$USER/current
 
I hate shared drives!! Things move/disappear/get-editted-by-Mr-Nobody... :evil: :evil: :evil: :evil:

What my team use is basically cvs (Concurrent Version System) for everything - spreadsheets, word docs, database schemas, source code, makefiles, scripts, xml blah blah blah - everything!

Everyone can have their copy on their box but there is a central server with the master and a tamper proof history of all changes. :wink:

These days you might be best off using subversion but I have no experience with that. Also SharePoint seems to work well for what it does.

Both cvs and subversion are open source and cross platform (but strongly suggest you use a "real" server for your repository - Linux/solaris/BSD not MSjunk)

YMMV - but good luck. :grin:
 
Shared drives.

Wiki.

Subversion: A program that acts like a shared drive but you have to "check-out" files and then "check-in" the same file. If you edited it, then it updates the old file. It locks everyone else out while you edit and keeps a record of who, what and when.

Agile: Database application for document control.

Meetings all the time.

That's how we do it in corporate America.
 
Disclaimer: not a pro, just a student working on a collaborative project (HW+SW) with ~7 other team members, so the workflow is a bit less formal/structured than in the real world.

We use http://trac.edgewall.org/ , which includes version control (Subversion) which we use for almost everything (not only source code but also schematics, PCB layouts, Eagle parts libraries, whatever Excel lists, datasheets, ..., all sorted into general and project specific subfolders), a wiki and an issue tracker/ticket system. The latter --although being designed for software development-- works amazingly well for all kinds of tasks.

Trac is open source and runs just fine on an old Pentium III (unless you heavily use it to compare different source code revisions which seems to take a few seconds with a PC that slow).

It took very little time getting used to always checking in changes and changing a few (bad) habits, and it did not get in the way of the existing workflow. I now can't imagine how to get anything done in a team project without trac or any similar system...

Matthias
 
Can subversion run accross the web?

with a distributed development team across multiple states (and countries soon) being able to share files would be very useful, as well as share best practices.

I have Wiki in place for best practices (e.g. What hole size should I use for screws? What's the API 500 spec?)

I have Aligni in place for component management (e.g. Whats the standard cap we use for decoupling? How much do XLR jacks cost?)

I still don't have an easy to use subversion drive/folder that I can link to easily from a non-vpn'd PC and save to directly from Eagle.

Any ideas?
 
Subversion installed on home server -  ;D
Access Enabled from outside the house - ;D
TortoiseSVN enabled for use from my PC - ;D

Now... how do I use this darn SVN software?
I ahve 3 directories - Trunk, Release, Taps

Where the hell do I keep my schematics and boards?
Do I keep a local copy on my PC to work on then sync?

is there a dummies guide?

 
Yes, keep a local copy of the trunk and work off of that.  When you want to share, just use TortoiseSVN to commit.  In plain text files (e.g., source code), there are some spiffy extra things you can do with branching and merging edits within files, etc., but with a situation like yours, SVN can be used primarily as a shared, version-controlled central drive.  I wouldn't worry about branching and such since intra-file merging functionality is rather limited with non-plain text files.  Get used to basic use of the software and then explore branching and merging later only if you develop a need.

If you reach a milestone that you'd like to keep for posterity, tag it (right-click -> TortoiseSVN -> branch/tag).  This will move it to the tags directory.  If you want to work on that specific branch again, you will need to check it out to its own local repo (read: directory) or use right-click -> TortoiseSVN -> switch on the existing one. 

Now, for some pre-emptive problem solving that I give to each new software developer I'm teaching to use SVN:

1. Beginning users usually get a lot of error messages about working copy out of sync, etc.  This is because SVN insists that your local copy is fully synced with the central repository before it will allow you to commit.  Just do a SVN update.  Eventually you will reflexively update before every commit just to make sure.

2. When moving, renaming, deleting files, etc., make sure to use the corresponding SVN commands, not simple OS commands.  With TortoiseSVN, that means right-click -> TortoiseSVN -> rename or delete.  To move or copy files within a repository, hold right-click and drag, then select SVN move or SVN copy from the resulting pop-up menu.

3. Sometimes your local copy just gets messed up too badly, (usually when files are moved, copied or deleted outside of the SVN commands in #2).  A key sign is generally when it prompts you to run the cleanup command repeatedly, and the cleanup command itself doe not help.  To fix this, move the files in your local copy to somewhere else on your computer (yes: move, not copy - make sure they are no longer in the local repo).  Next, perform an update to get a fresh copy of the repository.  Finally, copy your backup back into the local repository and overwrite the old files (but not the hidden .svn directories, if you can avoid it).  Any files you've deleted since the last commit will also be back.  This will fix 95% of these problems.

If you have any more problems or specific questions, I'll keep an eye on this thread.

- E
 
Back
Top