koehn

Source code control metadata shouldn't sync by default

Recommended Posts

btsync should, by default, not sync the standard source code control metadata directories: .git, .svn, .cvs, etc. It's really annoying to need to put .SyncIgnore everywhere and there's really no reason to ever sync these (and very negative consequences if you do) it should be the default behavior.

I just had two local git repositories that were subdirectories of the folder I was syncing get corrupted.

Share this post


Link to post
Share on other sites

I like to *bump* this up. ".SyncIgnore" is the main reason for me to abandon Dropbox/Skydrive. Though it is sad we have to manually add filters to protect the VCS on all clients. If .SyncIgnore can’t be synced developers would like to see that the defaults included the above suggestions.

Share this post


Link to post
Share on other sites

We are open for proposals. If community will create such list we will add it to .SyncIgnore by default, so there will be no need to add it manually.

Share this post


Link to post
Share on other sites

I would also like to ignore .git folders. But how can I ignore them in each subfolder? I often have this scenario where I have A/B/C/D/.git and not A/.git.

I mean */*/*/*/.git is oviously not the best solution as it might be that I create another subfolder E in D.

Share this post


Link to post
Share on other sites

The list of files and stuff a developer would like to tell sync to ignore is immense. It is basically the same list that he would like to tell his VCS to ignore. Take a look at the gitignore project on GitHub for samples for various application types including Visual Studio, C# and C++. If .SyncIgnore was synched it would not be a big pain managing the lists yourself to your own needs… but in the end, when one thinks twice, sticking too VCS instead of trying to sync the working folder is probably much more pain free.

I still think that .git/, .svn/, .cvs/ should not sync, just to protect the tool from backfiring on people who still will try this lazy form of code management.

Share this post


Link to post
Share on other sites

We are open for proposals. If community will create such list we will add it to .SyncIgnore by default, so there will be no need to add it manually.

I second koehn, and would be in favor of the default .SyncIgnore containing entries for popular VCS metadata directories. I'd like to synchronize a large git repo of binaries across our local network without having cron/task scheduler jobs on each machine to perform git pulls (I'll just have that done on a single linux machine, and any changes will be propagated by BT Sync).

Here's a list of potential entries off the top of my head:

.git

.svn

.cvs

.hg

.bzr

Share this post


Link to post
Share on other sites

Actually I don't agree with this default exclusion, for what it's worth. :)

 

For years I've been working on a number of different git repositories on different machines, and relied on Dropbox to keep them in sync. It never ever disappointed me.

 

Now pay attention to this specific use case before you go off on a tangent. :) I'm not sharing the repositories in question with anyone. This is purely so that when I get up from my workstation to continue work on my laptop elsewhere, I don't have to commit-push-pull simply to be able to do this. Instead I can just continue working, because the sync has taken care of the rest. When I'm good and ready, I'll commit. When I'm more good and ready, I'll commit and push to the remote server for other developers to pull from.

 

I've cancelled my dropbox pro subscription of some years, and am now happily syncing everything with bittorrent sync. Having my private repos synced so that I can move mid-work from one machine to another, without having to remember which repos need to be pushed, is a use case that I support strongly. The fact that Dropbox has never dropped a stitch in all this time shows that it is possible.

 

That being said, perhaps I'm in the minority, so I would also be fine with simply being able to disable these default exclusions to support my use case.

Share this post


Link to post
Share on other sites

I also disagree.

 

I am working with synced git repositories for a few months now and had no problems so far.

 

On the other hand if you sync the working directory but not the .git folder there are lots of possible problems:

- Whenever you commit on one node you cannot update other nodes because they already have the changes and do not want to overwrite them.

- When you check out a different branch on one node all other nodes will get those files too but still think they are on another branch and see lots of changes.

 

As a consequence you should either sync the working directory and the metadata or none.

Share this post


Link to post
Share on other sites

I think any exclusion should be only in .SyncIgnore file,  btsync should not have any built-in exclusion.

The main reason can be seen on this message thread ... some people want to exclude .git, and other don't.

 

For me, it is ok to sync the .git , especially in "read-only" mode .. as a backup.

I would not try to really "sync" .git on 2 machines and using git on the 2 differents machines at the same time ...

 

I already had trouble with btsync with 3 peers A,B,C.

 

But I agree that by default, the .git, .svn, and so on .. should be in .SyncIgnore file by default.

Then it is up to the user to "un-ignore" them.

 

Now right now, I would LOVE to know how to ignore any ".git" from any sub folders as user "sts" asked.

 

I would also like to ignore .git folders. But how can I ignore them in each subfolder? I often have this scenario where I have A/B/C/D/.git and not A/.git.

I mean */*/*/*/.git is oviously not the best solution as it might be that I create another subfolder E in D.

 

 

I hope we don't have to put a .SyncIgnore in the parent of all the .git folder.

So if any one can explain how to achieve that, I would really really appreciate.

 

Something that work on first sync import, but also if I add a new .git later.

Share this post


Link to post
Share on other sites

fyi, I blocked successfully blocked all the svn folders (on windows) with the following line

.svn\*

 

for linux you probably need .svn/*

 

I also agree this should be the default functionality.

Share this post


Link to post
Share on other sites

I assume two different .SyncIgnore-Files would be perfect: One that is only stored locally, so one can define ignore-rules for each node individually, and one shared .SyncIgnore-File, so one can define "secret-wide" rules for ignoration?

Share this post


Link to post
Share on other sites

12345lamacun,

 

could you please describe in what way"secret-wide" Ignore differs from the current SyncIgnore?

 

I'm looking to cleanup the shares and my questions is simple: If I edit .SyncIgnore on THIS COMPUTER... does the .SyncIgnore changes propagate to my OTHER computers?

 

If the answer is yes or no, I think the desire is to have a ".SyncIgnore" file that propagets - change here, it updates everywhere.... and a ".SyncIgnore" that is location specific - change here and it only affects here.

 

I know I want that segregation.

 

There are things I don't want synced no matter where I am (Thumbs.db, desktop.ini, obj\, bin\, etc). There are things I don't want synced in specific locations (Work subfolder of my code repository).

 

How can I keep certain things synced, and certain things local?

Share this post


Link to post
Share on other sites

I'm looking to cleanup the shares and my questions is simple: If I edit .SyncIgnore on THIS COMPUTER... does the .SyncIgnore changes propagate to my OTHER computers?

No, .Sync/IgnoreList (formally .SyncIgnore) does not propagate between your devices.

There is however a related suggested in this post over in the Feature Request forum.

Share this post


Link to post
Share on other sites

Actually I don't agree with this default exclusion, for what it's worth. :)

 

For years I've been working on a number of different git repositories on different machines, and relied on Dropbox to keep them in sync. It never ever disappointed me.

 

I also disagree.

 

I am working with synced git repositories for a few months now and had no problems so far.

 

Thirdly disagree, been using this privately for years with git in dropbox and google drive, no issues for private use.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.