Arc Forumnew | comments | leaders | submitlogin
2 points by CatDancer 5426 days ago | link | parent

I'm still not sure what should be done regarding libraries

There are some advantages to keeping each library in its own branch:

- It makes the git development history for the library really clear.

- I can propose changes to a library and merge them in to the library branch, without getting messed up by independent merges happening to other libraries.

- If you're using library A and someone commits a change to library B which breaks A, but you can't go back because someone later committed C which you need, what do you do? Make a commit that reverts the B change? But what if someone else is using that B change? Separate branches avoids these kinds of conflicts.

But, of course keeping libraries in separate branches does make using the libraries harder. Instead of just checking out one branch, now you need to use the published versions of the libraries, or checkout a git repository for each library.

I do no longer recommend my idea of having the git commits for a library include their dependencies. That was a good experiment for me to try, and I learned a lot from it, but it turned out not to be useful.

If you do decide to give each library its own branch, then I recommend that the library branch not include the Arc sources: make it an independent branch. The easiest way to do this is to add the library to a new, fresh git repository, and then fetch the library commit into your Anarki repository as a branch.



1 point by shader 5426 days ago | link

I also agree with separate branches for each library. For one thing, it takes less effort to make the branch stand alone, and there is less chance of messing things up.

Also, they don't get in the way as you are not forced to read the list, and can choose to track as many or few remote branches as they like.

How about using one branch per library, and tags for versions? That way everyone can track the development and even add things, but the versions are the things that 'lib and others like it go for.

The only thing I'm wondering about branches for libraries is: how do you find them if you're trying to fetch them via 'lib? I think only major changes need to be in their own branches, like the hygienic macro system. Everything else should either be hosted separately or in the lib folder.

-----

1 point by CatDancer 5426 days ago | link

The only thing I'm wondering about branches for libraries is: how do you find them if you're trying to fetch them via 'lib?

I can think of three scenarios:

1. You're using the public, published version of a library that also happens to be in your git repository.

2. You're using an unpublished version of a library in your git repository: for example, you're testing your code against the latest development version of a library to see if they work together.

3. You're working on a library.

For #3, I presume you'd just be using 'load.

For #2, if you want to for example get the latest version of a file "foo.arc" in the "foo" branch, you can use git for that, e.g.:

  git show foo:foo.arc
For #1, you don't need to get the library out of git, you can use whatever mechanism we're all using to fetch and use a published library.

-----

1 point by shader 5426 days ago | link

For #3, I presume you'd just be using 'load.

I was hoping to use a modified version of 'lib that would allow me to type

  (lib binary)
when I meant

  (load "lib/binary.arc")
It has the advantage of less typing, and hopefully the concept that functions are not reloaded unless the file has changed. If I'm trying to test a new version of a function, I would rather selectively reload that function than the whole library.

-----