Re: dia-list Digest, Vol 96, Issue 11



On Sat, 14 Apr 2012 12:00:02 +0000
dia-list-request gnome org wrote:

 Message: 2
 Date: Fri, 13 Apr 2012 20:12:13 +0200
 From: Steffen Macke <dia diagramr biz>
 To: discussions about usage and development of dia
      <dia-list gnome org>
 Subject: Re: organization, workflow
 Message-ID: <4F886C7D 8090904 diagramr biz>
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 Hi yac,

 Am 04/12/2012 08:50 PM, schrieb yac:
 > *   How do you organize diagrams in such a project?
 I think you're in the best position to organize this. You're doing
the work and you should feel comfortable with it.
 > *   How do I orientate in the files? Would enabling window title
 > bars help, is there other way? or will this go away once I get the
 > grip?
 I've never working without window title bars. Is your screen so small
 that you have to get rid of them?
 If that's the case: How about getting a bigger/additional screen?
I have big screens but still it's a feature, i generaly dont need
those, so I dont have them.

 > *   Is it possible to have nested layers?
 What's your problem with "just" having layers? Do you use the
"Search" function already? In
 complex contexts, I often prefer search over navigational structures
 (like layers or file system trees)
I'm not a big fan of search, I know my fs, my files and my workflow.
Search for me is more like a backup solution which only have a chance
of finding what I want. But do you mean a FS search or something else?

 > I tried storing the files ungzipped in git for like a week but
 > it's a mess and grows quickly and diffs arent very helpfull.
 > Storing them just in binary would also grow quickly on frequent
 > commits.
 What's your current data size and weekly growth? What's the disk
space you have available?
 Unless you're exceeding your available disk space within your project
 period (or the next time you're
 going to upgrade your hardware), there's no need to worry (add a
little bit of safety margin, if you want to be on the safe side...)
 I've successfully storedgigabytes of binary data in subversion
(which is basically the same as git) without any problems. And that
was several years ago.
I dont like it in principle. Currently its pretty small, like 150KB per
file but it would easily grow into tens of megabytes just after a few
days of work and then cloning would be a pain. Also it there wouldnt be
any help with merging, or does someone know of a simple method to
successfuly do merges on the dia xml? So I would get only automatic
check that stable/repo doesnt have any newer version than I have, which
could be also solved by a little caution when working with redmine
(also i dont think there would be conflict often) while I would also
get big git clones and having to teach other people to use git.

 > *   How do you manage versioning, backuping and sharing?
 s. above I would go for git. If there's a problem, could you
describe it in detail?
 > *   Did you actually try using git for longer time? with what
 > results?
 What's your point here? Are you worried about git's reliability? You
 shouldn't.
 But of course, git is NOT a substitute for backups.
 In case you're replicating your git repository frequently to several
 machines and you ignore that risk
 that all these machines are compromised at the same time (e.g. by an
 attacker or virus), a weekly backup could be sufficient. But of
course, if your time frame is very tight and you have to avoid the
risk of a one week data loss at all cost, you'll need more frequent
backups...
Actually it can be. Like in environment of linux kernel, Torvalds
mentioned that he doesnt do backups anymore, it is sufficient to know
sha hash of his last commit and he can safely pull them from someone
else.


 Regards,

 Steffen

I think I could wrote the post in a summary like ... Have you figured
some workflow tricks that come with experience with dia?

Regards,
yac

-- 
"Ubuntu", an african word meaning, "Gentoo is too hard for me"



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]