download Command Doing Too Many Things

[jmwright]

I'm a little concerned that we've conflated two different concepts into the download command. The command can download changes for both the project and it's dependencies, and can also make a copy (clone) of a remote repo. The first operation is an update, and the second is a copy. I'm wondering if downloading a copy should be moved out into it's own operation called copy or something similar.

[m30-jrs]

I remember when we first developed the command list. As I recall, we were (and are) trying to balance two competing values.

• simplify version control command scheme for users who do not come from a software development background
• maintain a sufficient command list to fully manage repo contents

(Oops, early press of comment button.)

So, the issue at hand may be better expressed as what operations would a user without software development experience nominally expect?

I have been watching some engineers get used to svn recently, and one thing is for certain, the update with merge then commit cycle is counterintuitive for them. As is the whole checkout concept now that I think about it, especially since it does not involve locking the content on the server.

I believe users generally understand Google Drive/Dropbox. I wonder if we can borrow that metaphor.

• sync down - aka update (with merge since that is how update works)
• sync up - commit+push (throws error if a sync down is needed)
• sync - sync down then sync up

Not sure I buy it myself, but it is worth discussing. I also imagine lots of users would just run sync most of the time.

This would leave upload and download for initialization tasks (do an initial push of new top level component and clone an existing top level component). Which begs the question if those keywords (upload & download) best match those use cases. I kind of feel they don’t quite match. Not sure what terms to use instead... will think on it.

What do you think @jmwright?

[jmwright]

@m30-jrs Sorry, didn't get a notification of the update you made to this issue.

I think that most engineers I know would understand upload/download better than "sync". download all (default) currently does what you're suggesting sync down would do, unless you provide a URL. Then it does a clone from the remote URL. The current upload command does what you're suggesting that sync up would do. There's no command that does both sync down and sync up currently though.

Not quite sure what my thoughts are on this. I need to think it over for a bit.

[jmwright]

I spent quite a bit of time with STEMN back when they seemed to be in active development, and they natively supported Dropbox and Google Drive. While their system had drawbacks, it was pretty intuitive for non-coders. Your data was just always sync'd, and you could tag certain states of your code with something akin to commit messages. I'm not suggesting we adopt their methodology as it never completely set well with me, but maybe there's something to be learned from it. Maybe there should just be a sync command that does down and then up by default, and allows you to specify a message, if you want. We could still have subcommands to only do up or down, but both would be done by default.

This brings up another issue that has been on my mind since the early days of this app. Merge conflicts. git tends to put extra text in your files when there's a merge conflict to help you correct it. Non-coders usually end up interpreting this as "git corrupted my files, it sucks." I can't say that I totally blame them either. If we're syncing both directions, merge conflicts are going to happen pretty soon after there's more than one person on an engineering team.

[jmwright]

Ugh. Hit the close button when I was trying to scroll down. Continued below.

We're probably going to need to address merge conflicts if we're going to sync both ways for users, or they'll end up thinking Sliderule is corrupting their files.