Collective reply, because this thread has been in my inbox too long... also sprach W. Kaplan <walter.kap...@gmail.com> [2009.04.19.1640 +0200]: > The problems I'm aware of are: > > a) Having the big ~/Documents repository is as wrong as a single big > $HOME repository, because it's still a lot of unrelated stuff in one > place. I'm actually not perfectly sure why this is so bad.
It isn't, necessarily. It just means that you won't be able to pull it apart, e.g. only take stuff related to your thesis with you on the space-limited netbook, and still be able to use VCS as before. If you keep it all in one repo, it's all or nothing anywhere you go. > b) Since the ~/Documents/git-projects directory is being ignored > by the Documents repository I have to manually create it on the > other computer and manually pull the projects inside it. Right now > I only have to deal with 2 active projects, so I don't mind > managing this by hand, but what if I create more projects? Maybe > that will be the time to try the "mr" tool. Yeah, sounds like mr. > I read about but haven't actually tried the "mr" tool yet. I don't > think that I want to go down that road. As far as I understand it, > I could create repositories in different places anywhere in > Documents/ and would not have to remember them all, because "mr", > once configured, would take care of it. While this seems nice it > also seems inefficient to keep pulling repositories that will not > see any new commits ever though. With Git, you don't really notice it. Plus, mr can parallelise the pulls, so I'd say: just do it. > Looking at my current approach I feel like I'm using git for > several different purposes: simple synchronizing (of dotfiles), > synchronizing and archiving (of the Documents directory) and > actual project management. This makes me wonder if I'm trying too > hard to use one tool here. Maybe there are other tools to be > considered? I think Git is fit for all those purposes. also sprach Chanoch (Ken) Bloom <kbl...@gmail.com> [2009.04.19.2234 +0200]: > Keep in mind that if you have merge conflicts in your office > files, whether OpenOffice or MS Word, git and other version > control systems are much less likely to be able to do something > sensible about merging them. Less likely than what? I don't know any other tool that can sensibly merge those dinosaur formats. > I don't expect any other synchronization system can reconcile > these files any better though. When someone comes up with a good > way to reconcile these files, I hope we'll steal it and integrate > it into git. Yeah. Git does allow for custom merge drivers. > I use git for all of these things. There are a few places where I feel > subversion might be a better fit (a few particularly conflict-prone > configuration files are easier to blow away local changes without > creating the extra commits that git needs), but I'm going to make a go > of it with git. If it's just local, you can use git-reset or git-rebase -i to blow them away too... also sprach Rustom Mody <rustompm...@gmail.com> [2009.04.20.0829 +0200]: > Thanks to this push, good-ol MS has moved (unwillingly?) from doc (for which > your comments above are correct) to docx that is similarly at core xml and > hence text. > > > I don't expect any other synchronization system can reconcile these > > files any better though. > > This true today. And merging XML is not identical to merging program > sources. But is much closer to it than arbitrary binry data True, in theory. If you think that we'll be able to merge two separately-edited OOo or MS Office files anytime soon, you are underestimating the storage format requirements of WYSIWIG editors, and underestimating Microsoft's furious attempts to adhere to the standard without actually implementing it. Apart, even if you could identity the conflicts atomically, how would you alert the user to them? also sprach Chanoch (Ken) Bloom <kbl...@gmail.com> [2009.04.20.1532 +0200]: > Though I've uncompressed .odt files myself to get at the XML inside, > I've never seen one of these in the wild that wasn't ZIP-compressed, so > as far as version control systems are concerned it's still binary data. This wouldn't matter for Git, since Git only stores contents, even for text files, and invokes merge drivers to combine two different versions. For text-only files, the merge driver is just the easiest you could conceive, which is why Git can do such an awesome job. It's still line-oriented, so far from perfect yet. > (I'm not even sure how the format would keep the four separate XML files > together if they weren't zip compressed, so maybe the Wikipedia article > is wrong or unclear.) AFAIUI, Zip is part of the format specification. also sprach Kelly Clowers <kelly.clow...@gmail.com> [2009.04.21.0731 +0200]: > http://git.or.cz/gitwiki/GitTips > > In git 1.6.1 or later, try this in .gitconfig: > > [diff "odf"] > textconv=odt2txt > > (unoconv might also work) > > and in .gitattributes: > > *.ods diff=odf > *.odt diff=odf > *.odp diff=odf > > Note that I have yet to actually make use of this. This can actually give you diffs in the text, but you won't be able to make use of them, let alone merge any changes. This is because txt2odt is missing. ;) also sprach W. Kaplan <walter.kap...@gmail.com> [2009.04.21.1203 +0200]: > As I go along I decide to put more and more things under actual version > control, i.e. initiate specific repositories. It's quite interesting. > Who knows, at the current rate I will have 87 repositories myself in two > weeks. And? ;) also sprach Eric Hanchrow <eric.hanch...@gmail.com> [2009.04.19.2359 +0200]: > If you don't mind some random company holding your data, you should > look at http://www.getdropbox.com/ -- it's dead simple, works on *nix, > Windows, and Mac; and it automatically keeps old versions. No help > for merging, though. … until they go bankrupt and it's all gone. Or they change their terms of service and make it impossible for you to get the data. Or they have a super-crash and it's all gone. That could happen to you too, sure thing. But they made sure that you could not hold it against them. Maybe they anticipate it? ;) -- martin | http://madduck.net/ | http://two.sentenc.es/ one has to multiply thoughts to the point where there aren't enough policemen to control them. -- stanislaw jerzey lec spamtraps: madduck.bo...@madduck.net
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home