SVN - naming convention

[James William Yoon]

Also, on a related topic, we should try to keep to a consistent 
directory name casing convention too. For directory names, let's try to 
use all lowercase, and replace spaces with a single dash. It's the 
convention the devs seem to be using (a few exceptions in 
/scratchpad)--not that we're tied to their conventions, but it seems 
like decent practice to keep consistent across all of svn.

E.g.
./Chocolate is Happiness
becomes
./chocolate-is-happiness

Cheers,
James

James William Yoon wrote:
> Hey folks,
>
> Vicki and Tona are correct: date and the user committing the file are 
> stored by svn, so it's a bit redundant to have it in the file name. 
> Also, with all the cross-designer work that we encourage, the list of 
> initials may get a bit unwieldy (and redundant--imagine a mature 
> design file that had all the designers touched at some point during 
> its life cycle).
>
> Whether we should include a version number in the file name or rely 
> solely on svn's version/revision control system is something to think 
> about. Here are my thoughts:
>
> We should have a draft number to indicate some end of cycle (e.g., 
> Kiosk-Wireframes-Draft4-HomeScreen), and not have numbers for within 
> drafts (i.e., rely on svn to keep track of the changes within a 
> particular draft). This is what we've already been doing 
> anyways--keeping work and changes within a particular draft abstracted 
> from everyone else, and simply showing the end of a draft.
>
> Also, I think we should use the term "draft" when referring to one of 
> these cycles, as opposed to "version". My reasoning for this to avoid 
> possible confusion arising from non-core-designers distinguishing 
> between design versions and production versions.
>
> E.g.,
> "Fluid Engage version 0.3 is based on kiosk design version 3 and 
> mobile design version 8"
> vs.
> "Fluid Engage version 0.3 is based on kiosk design draft 3 and mobile 
> design draft 8"
>
> Maybe it's confusing any way you cut it.
>
> Thanks for starting this thread, Lee--I'm glad we're having this 
> discussion!
>
> James
>
> tona monjo wrote:
>> Hi everybody,
>>
>> I agree with Vicki in trying to keep file names as simple as 
>> possible, while maintaining the essential data. I'm afraid that if we 
>> create too complex codes, it will be harder to maintain consistency.
>>
>> I wouldn't neither include the date or the author to the name, 
>> because in this case we would be cloning files (each new version 
>> would have a different date). And for authors and following the 
>> example, if Vicky worked later 
>> on 10-21-09_FE_wireframe-sketches_kiosk-v4_JM-VM_1.jpg, she would 
>> create a new file 
>> named 10-21-09_FE_wireframe-sketches_kiosk-v4_VM_1.jpg, so the number 
>> of files would increase with each new version.
>>
>> I vote for the Vicki's proposal, but at the same time I think we may 
>> need in the future some convention to mark definitive versions 
>> -although a design is never definitive!-. I mean versions that are 
>> "the last one" before releasing a development.
>>
>> Something like this?:
>>
>> kiosk_home_DEF.ai
>>
>> Cheers,
>>
>> Tona
>>
>>
>> On Thu, Oct 22, 2009 at 9:56 PM, Victoria Moulder <vmoulder at sfu.ca 
>> <mailto:vmoulder at sfu.ca>> wrote:
>> >
>> > Hi Leah,
>> >
>> > SVN assigns the date and author (person who has committed file) 
>> name to each file - so I don think we need to include this info in 
>> our naming convention?  Also, if we are placing the files in a 
>> directory called ...FE/ I'm questioning if would need to included 
>> this info??
>> >
>> > I'm thinking more: (micro project name)_(what it is)_(file 
>> description).file extention
>> >
>> > Example: kiosk_wireframes_sketches.ai 
>> <http://kiosk_wireframes_sketches.ai>??
>> >
>> > That's my 2 cents!
>> >
>> > V
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Leah Maestri" <leahmaestri at gmail.com 
>> <mailto:leahmaestri at gmail.com>>
>> > To: "James William Yoon" <james.yoon at utoronto.ca 
>> <mailto:james.yoon at utoronto.ca>>, "Kevin Muise" <muisek at gmail.com 
>> <mailto:muisek at gmail.com>>, "Vicki Moulder" <vicki.moulder at gmail.com 
>> <mailto:vicki.moulder at gmail.com>>, "Jess Mitchell" 
>> <jess at jessmitchell.com <mailto:jess at jessmitchell.com>>, "tona monjo" 
>> <tonamonjo at gmail.com <mailto:tonamonjo at gmail.com>>, "fluid-work List" 
>> <fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>>
>> > Sent: Thursday, 22 October, 2009 12:00:39 GMT -08:00 US/Canada Pacific
>> > Subject: SVN - naming convention
>> >
>> >
>> > Hi all,
>> >
>> > I thought I'd start a discussion around the naming convention for 
>> the files we're uploading to SVN.
>> > Currently we're plopping things in without rhyme or reason and this 
>> can very quickly come back to bite us.
>> >
>> > I wanted to bring up a naming convention Kevin thought of a few 
>> weeks back. Here's an idea for a convention that has worked in the 
>> past for managing files:
>> >
>> > Date(MM-DD-YY)_project name abbreviation_ type of work 
>> description_title_author(s) abbreviated_version number.
>> >
>> > So if we were to use James and Vicki's sketches, they would be called:
>> >
>> > 10-21-09_FE_wireframe-sketches_kiosk-v4_JM-VM_1.jpg
>> > 10-21-09_FE_wireframe-sketches_kiosk-v4_JM-VM_2.jpg
>> > 10-21-09_FE_wireframe-sketches_ kiosk-v4_ JM-VM_3.jpg
>> > 10-21-09_FE_wireframe-sketches_ kiosk-v4_ JM-VM_4.jpg
>> >
>> > We may want to consolidate files like these into one PDF so they 
>> are more manageable.
>> > Any thoughts?
>> >
>> > Best,
>> > Lee
>> >
>> >
>> > _______________________________________________________
>> > fluid-work mailing list - fluid-work at fluidproject.org 
>> <mailto:fluid-work at fluidproject.org>
>> > To unsubscribe, change settings or access archives,
>> > see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>>
>>
>> --
>> Tona Monjo
>> Disseny d'interficies | Diseño de interfaces | Interface design
>> http://www.tonamonjo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091023/bb0d6654/attachment.html>